At Devbridge, when we work with our clients to define a product backlog, a product owner will collaborate with client stakeholders, designers and developers to define product requirements in the form of “user stories.” These user stories are grouped into a set of features and epics to form a product release backlog.
Once a release backlog is populated with user stories, our design and development teams work to estimate each user story using a unit of measure called “story points.” By adding all the estimated user stories in a release, we can determine the total size of a release.
A release is broken down into sprints, or two-week iterations of incremental product deliverables. During a sprint, the development team commits to delivering a set of user stories during that two-week period. A sprint is considered successful only after the following criteria are met:
- The team delivers all the committed sprint stories
- All stories are accepted by the product owner
- The team produces a demonstrable and valuable product increment to the client
- The team isn't emotionally broken or battered in the process
The success or failure of sprints can have a significant impact on a product's release date and total project cost. At Devbridge, we use some simple tactics to ensure successful sprints. The suggestions below are recommendations based on our experience with agile software development. Be adaptive. Be agile. Use what works best for you.
Account for all technical tasks
The most common issue we run into with clients is when a team does not properly account for technical user stories. Just like a painter cannot start painting without first buying paint and brushes, taping up wall trimmings and laying drop cloth, developers and testers need to prepare and maintain their workspace by setting up solution environments, code repositories, continuous integration servers and fixing bugs. All that effort takes time and needs to be accounted for.
Like functional user stories, technical user stories also need to have effort estimates. Without tracking technical user stories, the backlog will not accurately represent the total effort involved in a release, and will ultimately result in inaccurate release forecasts. This issue becomes apparent in sprints when development teams spend time doing tasks that aren't represented in the backlog, while also failing to complete stories that are committed in the sprint. Unless you want to spill paint everywhere, be sure to account for the effort to lay your drop cloth and track your team’s technical user stories.
Keep stories small
During sprint planning ceremonies, the team is responsible for determining which user stories to deliver in the upcoming sprint. User stories are typically estimated in story points using a simplified Fibonacci sequence (1, 2, 3, 5, 8, 13, 20, 40, 100). This approach makes it easier to quickly estimate user stories without getting into a debate about the exact effort in hours.
To ensure successful sprints, do not accept user stories larger than 13 points into a sprint. When a team encounters a user story that is more than 13 points in size, either the story can be broken down into multiple smaller user stories, or the team does not understand the story enough to take it into a sprint. Like Russian nesting dolls, a user story can almost always be broken down into smaller stores.
For example, a 20-point story could be broken down into two stories: one story with 13 points, and another with eight points. In the case where a user story cannot be easily broken down into smaller stories, it is likely the team does not fully understand the story. In this scenario, consider adding a technical spike to the sprint to evaluate how best to approach the story, and then move the unbreakable story to the next sprint. This approach ensures that you only start user stories that the team fully understands, thus increasing story completion rates, and reducing the urge to split partially completed stories.
Don't take credit for partially completed stories
Simply put, a user story is not done until it's completely done. If the team commits to a 13-point story in a sprint, and the team only completes half of that story's acceptance criteria, the whole story must be moved into the following sprint. Do not pass “Go”. Do not collect $200. Splitting a user story and taking partial credit is like taking a vacation, arriving at your destination's baggage claim to pick up your luggage, and finding out that only half of your luggage was transported.
Splitting user stories and taking partial credit creates a behavioral anti-pattern that should not be encouraged - rewarding a team for incomplete stories. Would you reward an airline that lost half of your luggage? If the user story could have been partially completed, then it should have been broken down into smaller stories during the sprint planning ceremony.
This approach is also important because it indicates when you need to correct your team’s sprint velocity. Your team believed that they had enough velocity to complete a 13-point story, but clearly did not have the available bandwidth. By removing 13 points from the sprint velocity, and planning to deliver 13 fewer points in your next sprint, you are correcting for an overinflated team velocity and increasing the likelihood of successful future sprints.
Implement WIP limits
Let’s do a quick exercise. Say each letter of the alphabet in your head, and then count the numbers 1 to 26 in your head. Go ahead, try it.
How long did it take you?
Now say each letter of the alphabet in your head while counting the corresponding number (1A, 2B, 3C, etc.).
Can you even do it?
Most people can’t. The reason is because humans are awful when it comes to cognitive multitasking. Context switching between tasks is one of the biggest time-wasters in software development. Because of this, it’s important to limit the number of user stories a team member is working on at any given time during a sprint. This means that developers and testers should not work on more than one to two user stories at a time, otherwise they risk spending too much time on each user story.
Chart taken from Mike Cohn's Agile Estimating and Planning.
A team can reduce the number of active user stories by implementing work-in-progress limits, often called “WIP limits”. These limits increase delivery focus, highlight delivery bottlenecks, reduce context switching and prevent developers from starting stories they can’t finish. WIP limits are by far the most effective tool in your arsenal to ensure successful sprints.
Size really does matter
We all know that backlog stories should be prioritized based on customer business value, but what about story size? If we don't start large stories early enough in a sprint, we are less likely to complete them. We also can’t take credit for partially completed stories, so it's important to ensure larger stories are completed first.
The result is that larger stories automatically receive a higher priority in the sprint backlog. This approach forces you to consider how many large user stories to commit to in a sprint, and reduces the need to split partially completed.
How long would it take you to walk from your home to the nearest park? What about across town? What about across the country? How confident are you in each estimate? As the amount of effort involved in a task increases, the confidence and accuracy of estimates decreases. This means larger user stories are more likely to take longer to complete than we perceive.
Chart taken from Mike Cohn's Agile Estimating and Planning.
By keeping stories small, and limiting the number of large stories you include in a sprint, you can reduce the risk of failing a sprint.
Review stories as they are completed
Let’s say you want to order some delicious Chicago Style deep-dish pizza, but instead end up receiving a frozen, mini pizza bagel. Would you be happy? I mean, pizza is pizza, right? Do you think you would have been able to correct this mishap if you were watching the chef prepare your pizza?
Traditional Scrum training suggests the development team present completed stories to the product owner at the end of the sprint during the sprint review ceremony. In theory, this may seem reasonable, but in practice this is a mini pizza bagel waiting to happen. The end of the sprint provides little time for a product owner to provide useful feedback to the team. User stories that are not accepted by the product owner are considered incomplete, and as a result, the sprint fails. To ensure successful sprints, add a review step to your development process to get feedback from your product owner as stories are completed in real time.
Change your sprint duration
Every failure presents an opportunity to learn and improve. At the end of every sprint, your team should run a sprint retrospective to evaluate what went well, what didn’t go well, and what steps your team can take to improve.
If your team’s sprints are failing, then make them fail faster so you can learn sooner. If your team runs two- or three-week sprints, consider running one-week sprints to iterate through improvements faster.
Still having problems getting successful sprints out of your teams? Consider reaching out to Devbridge for agile consulting and software engineering expertise.