The current version of the Scrum Guide mentions “done” twenty-nine times, with the final section of the Scrum Guide being about the Definition of “Done.” What does “done” mean? It means potentially shippable, or according to the Scrum Guide, “useable, and potentially releasable.” Scrum is all about getting to done. There’s no partial credit. Shippable work is either done, or it isn’t.
That said, the sprint itself is considered successful if the sprint goal is accomplished. If anything needed to accomplish the sprint goal was not “done” before the end of the sprint, then the sprint wasn’t successful. This generally means that there were unfinished (or even unstarted) sprint backlog items remaining at the end of the sprint. But is that always a bad thing? Is not completing all sprint backlog items synonymous with not achieving the sprint goal?
It’s important to understand the difference between having a successful sprint (the sprint goal was achieved), and a sprint where all sprint backlog items were completed. Scrum teams aim to have sprints where all backlog items are completed, but a team that is achieving this 100% of the time probably isn’t stretching or growing. They aren’t pushing the boundaries of their own abilities and gaining the improvement that comes from that.
They also may be setting themselves up for failure if every single item on the sprint backlog is required to be completed in order to consider the sprint a success.
Scrum teams should be purpose-driven in their development. Rather than focusing on how many items get completed during a sprint, the focus should be more on achieving overarching business goals for delivering value to the customer. In other words, a sprint goal provides the strategic purpose for the sprint, but the tactics for accomplishing that goal can be flexible.
What Makes a Successful Sprint?
So, what does it really mean to have a successful sprint? How do scrum teams plan for success in a sprint? What is the real impact, large or small, of unfinished work at the end of a sprint? Let’s look at how each of the scrum events contribute to the scrum team’s success.
Sprint Planning
Scrum teams often have failed sprints because of how they planned them. They overburden the sprint, or make it so that the sprint goal relies on all of the sprint backlog items being completed. A better approach may be for the scrum team to plan so that their sprint goal can be achieved, skeletally, by let’s say 80% of the backlog items in the sprint. The other 20% of backlog items may potentially make it better, but give the scrum team slack to accomplish the goal of the sprint even when things don’t go according to plan.
Another issue is ignoring the team’s demonstrated empirical data of what they have been able to accomplish in past sprints (one example being their velocity—the amount of estimated work completed in a sprint). Often scrum teams overload their sprints by tweaking the math. See if any of these phrases sound familiar:
- “Well, those three items are really light fives, not heavy fives, so we’ll add another couple of items to the sprint.”
- “That backlog item was already started, so we’ll assume it’s a three instead of a five.”
- “We’ve been delivering 40 points every sprint, but if we work hard, I’m sure we can do 60.”
- “Well, we’re at our capacity, but John doesn’t have anything to do.”
All of the above phrases are attempts to tweak the numbers and ignore demonstrated velocity. Tweaking the math tends to add other problems to the team, like siloing and focusing on utilization instead of delivery. If the numbers don’t add up, the team’s chances of failing the sprint increase dramatically.
Daily Scrum
Each daily scrum is an opportunity to examine progress towards and recommit to the sprint goal, as well as to adjust the plan for what’s needed to move closer to achieving the sprint goal that day. This may mean shifting responsibilities. This may mean helping someone else on their task. But the important thing is that every action furthers the team’s progress towards accomplishing the goal.
During the sprint there should be an emphasis on finishing sprint backlog items over starting them. We call this swarming (all developers on the team work on the same user story until it is finished before starting a new one). For example, let’s say that there is a scrum team whose normal velocity is 25 points. They commit to five backlog items, each worth five points. A team member gets sick, and their estimated capacity for the sprint is going to be less than 25. It is better to finish the sprint with four backlog items done and have one unstarted than to have all the items started and have two or more items started but unfinished. Focusing on finishing backlog items will deliver four items, while focusing on starting multiple items at once delivers three at most, possibly zero.
This emphasis on finishing sprint backlog items means that any time a team member finishes their task, they should ask themselves two questions before moving on to a new user story and increasing work in progress:
- Can I help someone else on their task by pairing?
Team members have a responsibility to work together to help accomplish the team’s sprint goal. - If there is nothing I can help with, can I shadow someone and learn an additional skill?
If the team member truly can’t contribute to the sprint goal by helping someone else, then it becomes important that they cross train with other members of the team so that they will be able to contribute in the future if the team has another sprint goal that is similarly biased away from their current skill set.
The answer to one of the above questions will almost always be yes.
Sprint Review
While the sprint review is at the end of the sprint (after all work has satisfied the scrum team’s definition of done), it provides essential feedback that helps inform the planning of the next sprint. This is also an opportunity to discuss priorities with stakeholders and figure out what could be an appropriate sprint goal for the next sprint.
The sprint review is more than a one-sided show and tell. It is a collaboration between the team and stakeholders about the current state and future direction of the product. This can only be a useful conversation if what the stakeholders are reviewing is actually shippable—something they can interact with and give tangible context of what should come next. Being clear on what the next sprint goal should be is how the product owner provides strategic and clear direction to the scrum team.
Sprint Retrospective
What to do during the sprint retrospective depends on the sprint goal completion rate. If the development team is still completing all of the backlog items in the sprint for the vast majority of sprints, then the tone is much more about what learning can be gained from the failure than it is about completing all of the items in the sprint. The team can discuss questions and improvement action items such as:
- Were there external factors that happened that prevented us from completing all items? Can these be alleviated or prevented?
For example, the database instance may have run out of memory, causing an outage that pulled the team from sprint work. The learning may be to create an alert that will go off if the database is running out of memory so that the team can act on it before it becomes an outage. The unsuccessful sprint has helped the team to create a more robust system. - What bottlenecks did we discover in our work or process? How can we address those?
For example, the developers feel they spent a lot of time waiting for code reviews. The team agrees that no item should be waiting for a code review more than an hour, and will track how long each check-in had to wait. A team pushing themselves has helped them identify a bottleneck that they wouldn’t have found without stretching themselves. - Were there things we tried that were new to us? Are there areas of learning that we need to be aware of?
For example, the team was working with a new framework, and felt that some items were unfinished because of the learning curve. The team creates a time box for the next sprint to go through some tutorials on the new framework.
If the sprint goal was not achieved, or the team is consistently falling short of completing all sprint backlog items, then the discussion needs to shift a bit from learning opportunities to a stronger focus on how to accomplish the next sprint’s goal. Discussions and action items might include:
- What are we doing ineffectively that causes us to miss our sprint goal and not be as reliable?
For example, the team may not be accounting for interruptions (business meetings, vacations, etc.), or quality issues and technical debt may be slowing down the team’s velocity. - Why is it important to the business that our team be reliable in achieving our sprint goals?
This can help the team to understand and empathize with the need for the rest of the business to be able to rely on the team’s ability to plan and budget so that mobilization of other parts of the organization (e.g. marketing and sales activities) can be in sync and succeed together. This can also help the product owner to understand that their job is reliant on the team’s ability to be consistent and help the product owner to help protect the team’s focus as well. - What are we going to do to commit to and achieve next sprint’s goal?
Quite often this means committing to less (i.e. building in a little more slack than in previous sprints) the next sprint. It will be important to educate both the team and stakeholders that consistency is more important than a one-time high score.
After the Sprint
As far as what to do with unfinished backlog items after the sprint, there is really one answer: they return to the product backlog and get reprioritized accordingly. If the sprint goal was achieved, and there are any unfinished backlog items (remember the 80% guideline above), it is not automatically assumed they go to the next sprint. In fact, it’s probably more likely that any unfinished backlog items will go lower in the product backlog in favor of other product backlog items that support the product owner’s next focus that will serve as the next sprint’s goal.
If a backlog item that has been started will not be worked on in the next sprint, it’s changes should be backed out of the code, leaving the sprint’s product increment clean and shippable (these may be saved in a patch that can be applied later when the item is worked on).
Results You May Expect
<>Being purpose-driven with each sprint, and focusing on getting to “done,” expect to enjoy great results, including:
- Quality Assurance: Done actually means shippable. If the team isn’t delivering quality (work that delivers to the intent of the customer), it doesn’t matter how much they deliver. There’s a phrase used in firearms training that applies here: you can’t miss fast enough to win.
- Quality Control: Developing to a consistent definition of done on every product backlog item should significantly reduce the number of defects in production, if not eliminate them.
- Consistency: Variance in = variance out. Consistency is useful for planning, but is also a prerequisite to improving velocity. Because scrum teams do the same type of work from sprint to sprint (i.e. every sprint backlog item meets the same definition of done), they have a good idea of how much work they can accomplish each sprint. If a scrum team’s velocity is inconsistent from sprint to sprint, it is difficult to measure the impact of an experiment. If a team is consistent, they can try something new, and see if it impacts velocity positively or negatively, and adjust accordingly.
Once the scrum team is getting to done, delivering on a consistent basis, then they are equipped to push their boundaries to deliver more business value every sprint—something that can only be achieved after quality and consistency are present.
We help scrum teams get to done every day and achieve their goals every sprint. If you’d like to see that happen with your teams, contact us.
