In this introductory-level article we look at the mechanics of a Sprint, and at how team members are expected to collaborate in order to produce a release-quality increment.
The first day: Sprint Planning
The whole team, including the Product Owner, meet on the first day of the Sprint and conduct a Sprint Planning session. This is the very first thing to happen as soon as the Sprint commences.
Preparation
Sprint Planning ought to be prepared for. The most important preparation is to ensure that the Product Backlog has been refined to an appropriate level of detail, with estimates and acceptance criteria (this is the purpose of Product Backlog Refinement). Next, the Product Owner should have ordered the work on the Product Backlog, and have a general idea of how to negotiate a valuable Sprint Goal with the team. The options for negotiating a Goal should also have been considered during Refinement, and reflected in backlog ordering. Also, the team should have an idea of their capacity for this Sprint, which is to say, how much work they believe they can take on. They may be able to use their experience with previous Sprints to help them ascertain the size of this budget.
First plan the value that will be delivered
Each Sprint should result in a valuable increment of completed work, fit and ready for immediate release. The Product Owner is wholly accountable for what “value” means, and ought to have ordered the Product Backlog in such a way that value can be maximized by the team, sprint-by-sprint. The first thing the team must do is therefore to plan which items from the Product Backlog should be worked on in this Sprint, so that the best value can be delivered by the end of it.
To do this, the team work with the Product Owner to select the most valuable items from the Product Backlog which fits their projected capacity for the Sprint. Bear in mind that each item on the Product Backlog ought to have been given an estimate by the team, so they will know roughly how much work is likely to be involved.
Be sure to agree a Sprint Goal
This selection of work should be cohesive, and not just a grouping of unrelated and disparate items. Remember that a Sprint is a time-boxed opportunity to achieve something significant. For example, by the end of the Sprint a coherent feature may have been delivered, or a significant risk will have been mitigated. The Sprint Goal is a simple expression of this purpose, of the overarching significance of the work selected, and the coherence behind the selection.
A good Sprint Goal will allow the team to demonstrate focus and commitment, and allow collaboration and the re-planning of work so it is met.
Next plan how the work will be done
A Sprint Backlog is more than just a selection of work with an end goal in mind. It is also a plan for how that goal will be achieved, and how the associated work will be performed. This can be done by identifying and ordering the technical tasks that are likely to be involved. In effect the Sprint Backlog is a plan for meeting the Sprint Goal, and a forecast of the work that will have to be done.
The Product Owner does not need to be present for this part of Sprint Planning, as it is up to the team to plan this forecast at a technical level. However, the Product Owner should be available, even if only remotely, to answer any questions the team may have, and to provide any clarification that may be needed about the scope of the work. If more than one release is expected during the Sprint, this should be agreed with the PO and accounted for in the Sprint Backlog.
By the end of Sprint Planning, a team should be confident that it has made a good forecast of the work that will be needed to meet the Sprint Goal. It will have captured that plan in the Sprint Backlog which the team wholly owns. The team should be able to begin implementing that plan immediately and with a clear understanding – such as a Sprint Burndown - of how much work remains at any given point.
Each day, every day
Once the team have planned their Sprint Backlog they can start work. If they have planned things out as tasks, they will collaborate with each other, as a team, to make sure that those tasks are completed. They’ll be able to track their progress by using their task board and their Sprint Burndown of work remaining.
Each team member will be sure to keep the Scrum Task Board and the Sprint Burndown updated, so the information can be relied upon by others. An information radiator should always tell the truth.
Hold a Daily Scrum
Every working day, at the same time, the Development Team will meet and plan what they will do to bring them closer to the Sprint Goal. This meeting is called the Daily Scrum and it should never take more than 15 minutes.
Only Development Team members should participate, as the plan of work belongs entirely to them. It is a time-boxed opportunity to re-plan the Sprint Backlog as a result of new discoveries and lessons learned during the Sprint. The whole team should participate. Each team member should be able to account for:
- What they did yesterday to help the team meet the Sprint Goal
- What they intend to do today to help the team meet the Sprint Goal
- Any impediments which are getting in their way
By the end of the Daily Scrum, the team should have a clear plan for the next 24 hours and an understanding of how they will need to collaborate in order to achieve it. They should also have a list of any impediments which require the Scrum Master’s attention.
Refine the Product Backlog
In Scrum, Product Backlog Refinement is not a formal event but an ongoing activity - the process of adding detail, order, and estimates to Product Backlog Items such as User Stories. It’s up to Scrum Teams themselves to decide how often to do this, although it’s certainly a good idea for them to build refinement into their daily routine. Refinement shouldn’t take more than 10% of a team’s total time during a Sprint. For most teams, half an hour a day may be adequate although some may prefer to spend an hour or two a couple of times a week. The important thing is to make sure that the Product Backlog is refined in a timely manner so that Sprint Planning can occur without impediment. The whole team, including the Product Owner, should participate.
A refinement session typically begins with the Product Owner presenting the current Product Backlog to the team. The backlog may be held in a number of forms, such as an electronic Scrum Board or other collaboration tool, or it may simply be a spreadsheet. A projector or shared screen can be very useful.
The team start at the top of the Product Backlog and work their way downwards, refining each item in turn. They’ll examine each one and discuss its scope, and the acceptance criteria that will be necessary for its completion. Each item will then be estimated using a technique such as Planning Poker. A large item may be broken down into smaller ones which capture greater detail. Epics may be decomposed into user stories, for example.
The team stop once the session’s time-box runs out. They will recommence where they left off the next time, eventually starting at the top again so the backlog is kept up to date.
Always collaborate
In agile practice, team members never work in isolation – if they did, they wouldn’t be a team. In fact, teamwork is so important that the role is Development Team rather than Developer.
This means that each Development Team member must collaborate with his or her peers throughout the day, as they are jointly responsible for the progress of work. Any problems or failures are jointly owned by the team, as well as their successes. Collaboration is not something which is restricted to events such as the Daily Scrum, but applies to everything the team does throughout each entire Sprint.
Examples of collaboration include:
- Helping peers to complete work in progress before bringing in new work from a backlog
- Pair programming, such as taking it in turns to use the keyboard and helping and checking each other’s work
- Peer review
- Asking for help, and being keen to give it
- Going to where the work is and helping, instead of waiting for work to be passed over to them
- Making sure that all work does in fact meet the Definition of Done
- Calling a Scrum in order to resolve problems which need the team’s immediate attention
- Raising impediments to the Scrum Master so they can be handled in a timely manner
- Updating a Scrum Task board and burndown chart so that the information is up-to-date and can be relied on
- Skill and knowledge sharing
The final day: Review and Retrospective
Hold a Sprint Review
If a team has collaborated efficiently, they’ll have worked together to meet the Sprint Goal, managing any risks and adjusting their plans as necessary. They’ll have demonstrated control throughout the Sprint through an even burndown of work remaining, where each member saw it as their personal responsibility to help complete work in progress. They’ll have a valuable increment to demonstrate to the Product Owner and any invited stakeholders. A Review is something a team should look forward to.
It’s also something a team must prepare for. Enough time must be allowed for a demonstration of the work which has been performed. Tasks may be planned on a Sprint Backlog for this purpose, to make sure that the Review does justice to the work done and the value which is now available. Also, if the Product Owner thinks it would be a good idea to invite stakeholders, then those invitations ought to have been sent. The review is an opportunity to celebrate the work which has been done and to showcase their accomplishments, so confidence is inspired and a continued investment in the team might be justified.
A Sprint Review is also an inspect-and-adapt opportunity. It’s a good time for the Product Owner to explain how well the product is performing, to get feedback first-hand from any invited parties, and to draw any lessons which might be used to improve the Product Backlog further. If any work has not been completed, for whatever reason, then this will also be reviewed and re-estimated on the Product Backlog for possible planning into future sprints.
Then conduct a Sprint Retrospective
The Sprint Review looked at the Product and the value delivered, at the work which has been done, and honestly and candidly at any work which wasn’t done, whatever the reason.
The next thing to do is to conduct a Sprint Retrospective. A Retrospective considers the process which the team is following. Are they working as effectively as they can? It’s generally best to hold the Retrospective immediately after the Review, because the former can introduce ideas for consideration in the latter.
The whole Development Team, the Product Owner, and the Scrum Master must all attend the Retrospective, because everyone is jointly responsible for the success of the team’s work. It’s really important to have a free and open session which gets to the heart of any problems and identifies actions which will help to resolve them. A Retrospective may begin with the following declaration:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.”
In a “Retro”, everyone has an equal voice. One approach, which the Scrum Master may facilitate, is to identify:
- Things which went well
- Things which didn’t go so well
- Ideas for improvement
- Shout-outs for team members who did something exceptional
Establishing a time-line can help jog attendees’ memories about significant events during the Sprint.