This is a Comprehensive Guide for All The Important Agile/Scrum Terminology and is an All in One Glossary of Agile and Scrum Concepts:
As we all know Agile needs no introduction. It is a Software Development framework being used all over the world.
This article is a comprehensive guide of all the agile/scrum concepts you need to have at your fingertips.
Table of Contents:
Agile Manifesto
The Agile methodology is based on the Agile Manifesto. For more information on the manifesto, check Manifesto for Agile Software Development.
The key takeaway from the agile manifesto can be shortened down to:
- Person to person communication is effective for process binding.
- The working product is better than conventional step-by-step documentation.
- Client/business owner involvement is critical and so are continuous feedback loops.
- Changes are inevitable. Hence the Teams should embrace and welcome them.
You will see that, even though the agile process makes these declarations, it does not provide the exact concrete steps to achieve that. It grants complete freedom and autonomy to teams to do their best work.
Over time, the freestyle has evolved into common practices. Out of which the most famous one is Scrum.
Let’s start our definitions with that.
What Is Scrum?
Scrum is a developmental model developed by Ken Schwaber and Jeff Sutherland and has been in use since the 1990s.
Work is divided into smaller requirements (stories, epics, and tasks) and close-knit teams build and deliver in small installments. Feedback is sought frequently and improvements are made to the product in the form of frequent short releases.
Pillars Of Scrum
The pillars of Scrum are explained below in detail:
- Transparency: Teams are aware of what is going on and be open to sharing and helping each other. Communication flows freely via daily stand up and informal person to person interactions.
- Inspection: Frequent and religious inspections of work are the key to Scrum’s success. Teams can identify, diagnose, troubleshoot, fix and get back on track in a simple and reliable way.
- Adaptation: Scrum does not assume what they are doing is right. There are periodic checkpoints in the form of Sprint planning, daily scrum, sprint review/retrospective meetings where the team gets to review and adapt.
Scrum Team
Scrum teams are usually small (5-9) and they are usually cross-functional in nature. They include a Scrum Master, developer, tester (it is common practice to refer to all agile team members as developers irrespective of their field of work).
Other technical team members and most importantly, the product owner or sponsor. Agile places all of its bets on its team. So a self-organized A-team is critical and almost a prerequisite for a successful agile implementation.
Roles In Scrum
Given below are the various roles in Scrum:
- Product Owner: A product owner owns the backlog. He is responsible for the product and the shape it takes. Maintaining the product backlog, having an overall product vision and driving the team’s goals towards it are the primary responsibilities of a product owner.
- Development team: The development team does not have any confined roles. They are expected to work cross-functionally and choose the best approach to achieve the goal.
- Scrum Master: It is the scrum master’s job to make sure that the scrum is implemented in the right way. The scrum master is also called as the Servant Leader for the whole team.
Scrum Ceremonies
Agile relies on a few habits to stay on track and be successful.
Some of them are mentioned below:
#1) Daily scrum meeting: This is a typical 15 min short meet where each team member talks about the following points:
- What was done yesterday?
- What is planned for today?
- Are there any impediments along the way?
This format of the meeting is very effective to understand what work is finished, what is remaining and how the team can help each other if required.
Scrum Master facilitates this meeting, but it is not for the benefit of the Scrum Master or a place to collect the status. It is an opportunity for the team to interact and huddle together before they go their separate ways of conquering the tasks of the day.
#2) Sprint: A Sprint is a time-boxed iteration (often 3 weeks once but could be longer or shorter). This is a repetitive process and can be looked at as one burst of development and delivery.
#3) Sprint Planning: The purpose of sprint planning is to plan how to turn a set of product backlog stories into an increment of the shippable product.
The overall format can be like a 2 part situation.
- First Half – The team selects the items that they commit to complete.
- Second Half – Product Owner is available for questions.
The team decides on how to build it. Thus the tasks are created and assigned accordingly resulting in the Sprint Backlog.
#4) Sprint Review/Demo: After a sprint, the team and the stakeholders meet, so the work completed can be showcased.
The completed tasks are compared with planned items, and the functionality that has not been implemented gets omitted. The duration of this meeting is not more than 4 hours.
#5) Sprint Retrospective: This meeting is facilitated by the Scrum Master and the whole team including the PO attends it.
The team discusses the recent Sprint by keeping the process improvement ideas in focus and determines what changes could be made to make the next Sprint more productive.
Normally, this meeting takes not more than 2 hours.
=> Recommended Read – Agile Retrospective Meetings
Agile Estimation Basics
Given below are Agile Estimation Basics:
Inputs
- Product backlog and sprint backlog.
- Historical data, previous estimations for similar tasks with actual effort values spent on them.
Estimation Participants
- Team members familiar with the application.
- Team members who understand the application’s integration with other systems.
- Representation of various skills required for project completion.
- Build, deployment and QA team representatives.
Definition to Epic/Feature/Idea
- These are large user stories, typically too big to implement in a single iteration.
- Idea/Epic –> Stories – >Tasks (One Idea can have multiple stories. One Story can have multiple tasks. Story scope is limited to one Sprint. All tasks should get closed to complete the story)
#1) Story Point Estimation Technique: Story point is a number that tells the team how complex the story is.
In most cases, the Fibonacci series or T-shirt size is used. Usually, one story point is considered to be equivalent to one day’s work of a person.
However, the ratio is revised after every iteration based on the actual data of the average time taken to complete one unit of a task.
The steps involved include:
- Break very large requirements into small tasks.
- Choose a team of at least 2 estimators, the Scrum Master, Product Owner & the others can participate.
- Each estimator privately allocates his/her story points for a user story (task) and publishes the same.
- Story points for the requirement are allocated by the estimators based on their past knowledge of the size of a similar task.
- It is expected that the estimates will differ slightly.
- If estimates differ significantly, then high and low estimators explain their estimates.
- After this, one more round of estimation is done by all the estimators, following the same process until they all converge to the same number.
#2) Planning Poker: This interesting and fun technique is explained here: How to Make Agile Estimation Process Easy with Planning Poker
Note: There are many other techniques for agile estimation but these the two most prominent ones.
Scrum Artifacts
The most important scrum artifacts are Product Backlog & Sprint Backlog. These are the ones that aid in monitoring the overall sprint goals.
#1) Product Backlog:
- An ordered list of “requirements” that is maintained for a product/project.
- A list can contain bugs, and non-functional items as well.
- Product Owner is responsible for setting up priorities in the PBL.
- Product Owner is responsible for managing the Product Backlog.
#2) Sprint Backlog:
- To-do list (also known as Backlog item) for the Sprint.
- Scrum Team is responsible for maintaining them..
- During the sprint, team members are expected to update the sprint backlog as new information is available.
- In case if any of the items are left incomplete or partially complete then, as per the definition of standard scrum those items are put back into the Product Backlog.
#3) Burn Down Chart:
- It is a publicly displayed chart showing the completed and remaining work in the sprint.
- Shows the actual work that is completed by day-wise.
- Maintained by the Scrum Master on a daily basis.
- There are two types of ‘Release Burn-down charts’ & ‘Sprint Burn-down charts’.
Definition of Done
Definition of Done is different for different scrum teams. In simple terms, DoD is a way to tell when the team will achieve the goal via the available tools. It is the contract between the PO and the team.
DoD met means all the stories from the backlog are developed according to the stakeholder’s requirement. Stories could be non-technical or can have multiple tasks.
Backlog Refinement (Grooming)
Backlog refinement is not a core scrum practice but has been adopted as a way of managing the quality of backlog items entering a sprint.
It is an ongoing effort of reviewing the product backlog items and checking if they are appropriately prioritized and prepared in a way that makes them clear and executable for teams once they enter sprints via the sprint planning activity.
Quick Comparison With The Waterfall
| Parameters | Agile | Waterfall |
|---|---|---|
| Customer satisfaction | Customers are satisfied because of rapid delivery | Delivery is late so customers are unsure |
| Delivery of working software | Frequent deliveries | One every few months |
| Late changes | Can be scoped into the upcoming spring quickly | Difficult to implement |
| Communication | Daily communication | Review meeting with Project Manager |
| Dependency | Close communication and cooperation between business people and Developers – Testers. | Project manager drives the project |
Product Backlog
As we move upwards, PBI’s are created and they are DEEP:
- D- Detailed enough
- E- Emergence
- E- Estimated
- P- Prioritized
And they are more detailed to the team.
Things that a Scrum Master should adapt to:
- Removing impediments
- Facilitate
- Mentoring and teaching
- Coaching
These are the tasks that a Scrum Master should perform when the Scrum is newly implemented. But as time goes on and as the team gets used to Scrum (becomes Self-organized) the Scrum Master has a task to perform i.e.to ‘OBSERVE’.
Building A Scrum Team
While building a team, the Scrum Master could face the following challenges- Forming, Storming, Norming and Performing.
- Forming- Where there are no relations in a team.
- Storming- Where boundaries in between the team members would become light.
- Norming- When there is a good relationship established in the team.
- Performing- This is the last stage where there is only Team Work.
As we can see, the last stage is where the team really works as a Scrum Team. But during this transformation, if there is some disruption at any stage, then it takes the team back to the beginning.
Conclusion
We hope this tutorial has briefly explained all the important Agile And Scrum Terminology. Please refer to this tutorial series Complete Guide To Agile Methodology for details of Agile/Scrum concepts.
Happy Agility!