First published on Scrum.org, 24 February 2017. Republished in The Agile Zone, 1 March 2017
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.
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.
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.
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.
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 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.
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.
- 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.
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 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.
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:
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.
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.”
Establishing a time-line can help jog attendees’ memories about significant events during the Sprint.