What is Scrum?
Scrum is a simple empirical process that enables teams to build products incrementally in iterations, to keep abreast of the changing market needs and align themselves to the organization’s business goals.
Scrum advocates self-organizing teams working towards a common goal through continuous inspection and adaptation. A minimum viable product at the end of each iteration provides an option for the teams to quickly get feedback from end users and respond accordingly much faster.
3 Scrum Roles
The scrum team is made up of just three roles: a Product Owner, the Development team, and a Scrum Master
1. Product Owner:
A Product Owner in a scrum team decides what needs to be built. This person has complete knowledge on the market and business needs, has a vision, and owns the return on investment (ROI) or value delivered by the product.
Unlike traditional delivery, this person is a part of the team that delivers the product. Following are the key tasks of the Product Owner:
- Creates the vision
- Represents business, and is responsible for the ROI
- Cascades the vision to the teams
- Owns the backlog of features
- Prioritizes features by market value
- Is empowered to take decisions
- Negotiates with the team and business to deliver the right product at the right time
2. The Development team:
The Development team in scrum is the team that has all the skills necessary to implement the backlog items. This team is not any normal team and is committed, dedicated, and motivated to perform the best.
It is a self-organizing team that collaborates, shares their special skills and knowledge and are committed completely to fulfill the objective. The team members are empowered to take crucial decisions that can make or break a situation.
The following are the special characteristics of ‘The Development team’:
- Self-organizing - the Development team will be a self-managing group, who will decide on the tasks that they will work on incrementally. There is no ‘Manager’, who will be controlling their work
- Empowered - the team can commit to work, determine HOW to deliver and decide HOW MUCH to deliver in one iteration
- Cross-functional - the team does not segregate members as developers, testers or analysts and each have the necessary skills to deliver the product increment
- Small-sized - the Development teams should ideally have 5 to 9 team members with skills sufficient to deliver the committed work. Smaller teams will not have the bandwidth to complete a considerable work and bigger teams will increase complexity
- Co-located - the agile team is co-located, to ensure effective collaboration
- Committed - since the team is empowered to take decisions on the scope of work in a sprint, they are committed to delivery, should be transparent on the progress, and highlight the impediments early on
- Dedicated - this team is focused and is 100% dedicated to product delivery
Unlike traditional methodologies, where the commitment to deliver is made to business by the team that is not involved in the execution, in Agile, the team that does the work commits to how much work can be executed in a sprint.
The Development team decides how much work is to be done in a sprint, and commits to delivering a ‘potentially shippable product increment (PSPI)’, without sacrificing quality and speed. The team also makes continuous self-improvements.
3. Scrum Master:
The Scrum Master is not a management title and cannot make decisions on behalf of the team. The Scrum Master’s major responsibility is to ensure that scrum is understood and practiced by every team member in the true spirit.
The Scrum Master should understand the different skill sets of his team and group them by having the right sheep in the right flock. A Scrum Master should guide the team such that the team does not go astray and fall prey to excess time and energy. A shepherd must draw out quiet people during stand-up meetings or when planning poker sessions. And, when the team loses focus or a team member goes astray, the shepherd should bring the lost one back to the flock and guide appropriately.
The Scrum Master should not enforce agile practices on the team, but should don a ‘Servant leadership’ role. Scrum Master should lead by example and be a living demonstration of team assets and scrum values.
He should create an environment of safety for the team, and guide and facilitate team collaboration. He should refrain from solving problems or making decisions by guiding teams to do so.
To summarize, a Scrum Master:
- Is a servant leader - mentors and coaches the teams on scrum theory and practices, guides them on how they need to adapt to the same, thereby realizing the benefits of scrum both at team level and organization level
- Helps remove obstacles/impediments - supports the Development teams in removing the impediments by reaching out to the right people, thereby ensuring a smooth development progress without disrupting the team
- Facilitates collaboration - enables interactions within the team as well as between the team and the Product Owner
- Teaches scrum - to the team
- Protects the teams - from external disruptions like changes to stories in the current sprint
- Is a change agent - in growing the organization to deliver early and often, and removing waste
Scrum focuses more on a working software at the end of every sprint rather than comprehensive documentation. This does not imply that there is no documentation. The documentation is provided to facilitate collaboration and interactions, rather than tracking. The progress is measured always through a working software. Documentation in scrum is only through four main artefacts namely: Product backlog, Sprint backlog, Increment and Definition of Done.
1. Product backlog:
A product backlog is a dynamic list of functionalities the product might include, such that it provides value to users.
The Product Owner maintains this list and is responsible for creating, managing, and prioritizing the backlog by focusing on WHAT brings the highest value to the users. These are few unique characteristics of a product backlog:
- Is dynamic in nature as it evolves based on changing market needs
- Lists all the features and capabilities that will be taken up in iteration and delivered as a product increment
- Is refined on a continuous basis. The Product Owner and Development team collaborate and update the details, estimate, and prioritize based on business value and size
2. Sprint backlog:
Sprint backlog is a subset of the entire product backlog that the scrum team plans to implement in one iteration or sprint.
During the sprint planning, the team selects items from the product backlog that they commit to complete in one sprint and thus, creates the sprint backlog. The Product Owner and Scrum Master should not provide inputs that may impact the team’s decision. Sprint backlog has:
- Subset of product backlog items that the teams commit to implement in one sprint
- Items broken into smaller pieces of work as tasks
- A focus on HOW the team does the work and delivers the value in one sprint
- A story or task board that is used by the teams to view backlog and individuals sign up for work after prioritization
- Provision for the Development teams to track the sprint progress and check their alignment to sprint goals
An increment is the work delivered at the end of every sprint. Typically, after every iteration there will be a Product Increment (PI) that delivers value and the final product will be a working software. This increment is a sum of all the capabilities that were delivered in the previous sprints as part of the PI. A Product Owner decides whether to release the working product increment post the sprint or the release.
4. Definition of Done:
Scrum clearly states a ‘definition of done’ that enables teams to understand the meaning of marking a story as done. Based on this, teams measure the progress of completion of their stories. This not only helps identify ‘done’ items, but also helps decide on the total items to be worked in that sprint or iteration. The ‘definition of done’ is defined at various levels, which are release level, sprint level and even at the story level. The story level ‘definition of done’ is handled through acceptance criteria. In a multi-team scenario, teams mutually align to the sprint’s ‘definition of done’.
All scrum activities are time-boxed and allow teams to inspect their current work and implement those learnings in future time-boxes.
Heart of Scrum – The Sprint
At the heart of scrum, is the ‘Sprint’. The sprint is a time-boxed iteration, typically ranging from 1 to 4 weeks, at the end of which, a potentially shippable product increment is delivered by the Development team. The sprint has the following characteristics:
- Does not exceed a maximum of one calendar month, as this will increase the risk due to changes in requirements and thus, may not provide the perceived business value at the end of the sprint
- Has a goal or ‘definition of done’ associated with every sprint that actually measures the success of the sprint
- Can be cancelled by the Product Owner, if the goal or the need for the sprint becomes obsolete due to changing market
Scrum advocates specific types of activities, events, or meetings within a sprint to avoid the traditional formal meetings. These events and meetings are conducted at regular intervals and happen at specific periods of the sprint.
Typical scrum activities are:
- Product backlog refinement
- Sprint planning
- Daily scrum
- Sprint review
- Sprint retrospective
1. Product backlog refinement (continuous activity throughout the sprint)
Product backlog refinement is a continuous activity throughout the sprint, where the Product Owner ensures that the product backlog is in order. The Product Owner performs the following tasks to ensure that the product backlog is relevant:
- Removes or demotes product backlog items that no longer seem important
- Adds or promotes product backlog items that become more important
- Splits product backlog items into smaller items or merges smaller ones into larger items and estimates those
2. Sprint planning (2 hours per week sprint time-box)
Sprint planning meeting happens at the start of every sprint. This helps the Product Owner and Development teams to plan the product backlog items that will be taken up for implementation during the sprint. The Development team performs the following activities during this meeting:
- Considers and discusses product backlog items with the Product Owner
- Ensures a shared understanding on those items
- Selects a number of items that they estimate to complete
- Creates a sufficiently detailed plan to complete the selected items
To ensure that the above is achieved, two activities need to be done:
Part I: Define ‘WHAT’ work will be done
- Product Owner renders prioritized product backlog to the Development team
- The whole scrum team collaborates to understand the work
- The Development team alone decides how much work is to be taken without any pressure for more work to be done
- The sprint is given a goal called the sprint goal as the essential focus of that sprint
Part II: Explain ‘HOW’ the work will get done
- Development team decides how to produce the next product increment that meets ‘definition of done’
- Sufficient design and planning is conducted to complete the committed work
- Work to be done in initial days is split into small units of one day or even less
- Work to be done later are split whenever needed
3. Daily scrum (15 minutes)
Daily scrum is a 15 minute time-boxed event in which the team manages its daily activities. This is also called the daily stand-up meeting.
The scrum team meets every day, preferably at the same time and same place, so that it becomes a habit and here each member answers three critical questions:
- What did I get done yesterday?
- What will I get done today?
- Are there any impediments blocking me?
It is essential that all the members of the scrum team are available for the daily stand-up meeting. The daily stand-up meeting is for the Development team, and they should participate enthusiastically to collaborate with each other.
The daily scrum also ensures that the impediments blocking the progress of the sprint are identified and resolved without further delay. Detailed problem solving does not happen during this meeting. Unnecessary meetings should be avoided by broadcasting individual updates to everyone.
This event enhances team communication and transparency, thereby enabling teams to be self-organized and make faster decisions.
4. Sprint review (1 hour/week time-box)
A sprint review is an event that happens at the end of every sprint, where the teams and stakeholders discuss what was done in the sprint. The following happens during this meeting:
- A demo of the product increment showcasing the new features and underlying technology
- Feedback from the review provides input to the team to further discuss on refining the existing backlogs and plan for future sprints
- The Scrum Master facilitates this review meeting that is typically attended by all the stakeholders invited by the Product Owner
- Sprint review is essentially a way in which the team inspects and adapts to the next sprint and overall product release
5. Sprint retrospective (1 hour/week time-box):
During a sprint retrospective meeting, the Development team inspects the previously completed sprint and identifies areas of improvement to be enacted for the upcoming sprints. This happens after every sprint and right after sprint review in which the whole team participates. During this meeting:
- The team introspects on what went well in terms of collaboration, planning, process, and tools
- They try to identify potential improvements that can be taken up in the next sprint to make the scrum processes more efficient by learning from previous shortfalls
- They decide on what would be done in the next sprint by taking into consideration the major improvements
- Scrum Master ensures that the teams improve their skills and knowledge during the scrum process so that they become more effective in the next sprint
- The team focuses on improving their entire delivery cycle
The three typical questions the team answers are:
- What shall we start doing?
- What shall we stop doing?
- What shall we keep doing?
All the above activities in the scrum process framework enable teams to deliver a potentially shippable working software in short iterations. This also enables teams capture feedback, inspect, and adapt for the next iteration.
Scrum also states five core values to which teams have to adhere. The core values are: Commitment, Courage, Focus, Openness, and Respect. These values need to be imbibed and lived by the scrum team to ensure the fulfillment of scrum pillars of transparency, inspection, and adaptation. It builds trust among everyone.
Successful use of scrum depends on people becoming more proficient in these 5 values
- People personally commit to achieving the goals of the scrum team
- The scrum team members have the courage to do the right thing and work on tough problems
- Everyone focuses on the work of the sprint and the goals of the scrum team
- The scrum team and its stakeholders agree to be open to all the work and the challenges that they encounter while performing the work
- Scrum team members respect each other and consider each to be capable and independent