Picture this: The Scrum team has worked hard the entire two-week sprint. Developers have worked after hours to push code for QA to test to complete all the work slated at the start of the sprint. The final day of the sprint has arrived, and you still have eight story points untouched and incomplete, creating rolling user stories. The team feels deflated after working so hard to hit the goal of wrapping up all story points assigned in the sprint. Where did you go wrong?
The good news is, often there’s a clear-cut reason why stories are rolling from one sprint to the next. Whether there’s a straightforward solution, however, depends on the reason and the challenges the team may be facing.
Definitions:
Rolling user stories: When user stories aren’t completed in the current sprint and are automatically “rolled” or added to the following sprint.
Spike: A user story with an output of knowledge, refinement, or an answer to a question.
Fibonacci: A sequence of story points 1,2,3,5,8,13… based on the Fibonacci sequence used to estimate effort.
Story points: In short, stories should reflect the scope of effort against each other, not hours or an actual time metric.
Work in Progress (WIP): A concept describing work in progress, not yet completed, which means no value can be derived from the effort expended so far.
Suck -----------|-----------|----------|--------- Awesome
Suck: Never completing all stories
Medium/Midpoint: Completing 100% of the stories 100% of the time
Awesome: Completing all the stories 90+% of the time**
**A quick note on the awesome scale: It looks like there’s a typo, but in fact, it is better to complete 100% of the stories 90% of the time vs. completing 100% of the stories 100% of the time. The reason for the paradox is that there is a very easy way to achieve 100% of the stories 100% of the time: just plan for significantly less than you can complete under any circumstance. To avoid padding the sprint, the team should plan to capacity as much as possible. If it looks too good to be true (or too easy to accomplish), it probably is. Even the greatest basketball players don’t make every shot every time!
Common Reasons for Rolling User Stories to the Next Sprint:
Overplanning:
Once upon a time, I was working with a new team, and we were currently on sprint #10 (more on naming sprints later). The team’s cadence was in two-week sprints. I joined the team for the first time in their planning meeting. The team was averaging roughly 40 points a sprint. I say “roughly” because they were rolling user stories from sprint to sprint, making measuring velocity nearly impossible.
At the end of the planning meeting, they landed at about 80 points for the next sprint. The entire team was happy with that number. I jumped in and asked how many points they planned for the last sprint. Eighty was the unanimous answer. I then asked how many points they had completed the last time. Again, unanimously, the answer was 40 points. Looking at the expectation vs. reality, I asked them what great improvement they had implemented to be two times faster in the upcoming sprint—allowing them to jump from the 40 average to the goal of 80. Unfortunately, the only response was silence.
At this point, the team had the very common response: “But we have to get the work done or …”
Calmly (though somewhat sarcastically), I said, “If it makes you feel better to plan for 80 points, do it, but only if next time you will plan for 40 if you don’t end up completing 80 points. Actually, let’s allow 2 sprints to get up to 80 points, so there’s no question that 40 points is your velocity.”
The team did 40 points for the next 2 sprints, and we had the conversation that most teams never have. In our retro, we discussed the fact that the team had missed two times in a row, and there wasn’t anyone holding onto the misconception that 80 points were doable at this time by this team.
Scope Change/Unknown Difficulty:
An example of scope change and not being aware of the difficulty associated with the story may look something like this:
The team says story X is 8 points. They’re using an external API and software they haven’t used before. They begin working on the story and realize halfway in that the external API will require a lot of back and forth with the vendor, and the software they’re using will require an upgrade.
Suddenly this 8-point story has increased to at least 20 points of work.
Resource Issues:
This is a pretty basic issue, but it’s one that can be quite disruptive. Here are a few examples:
Susan expected she would be here all ten working days of the sprint, but two days in, a family member has a medical emergency, and she is out for the remainder of the sprint.
Or John says he is planning on taking only two days of PTO but ends up getting lost in the woods, his flight is delayed, or he arrives home ill and has to take off a couple of days to recover. As a result, he’s out for four days instead of two.
Injections:
The team starts the sprint with a clear sprint goal and a maxed-out story point commitment. Unfortunately, midway through the sprint, the Product team comes to the Scrum Master with an urgent request tied to a customer commitment. I’m sure you know this scenario all too well: it may even give you nightmares. Now the team has to find a way to inject new stories, all with a range of pointed values, into their sprint with only seven working days to go.
A Change to the Sprint Goal:
Similar to the scenario referenced above in injections, let’s say you’re midway through the sprint and the priority of the work currently in progress is suddenly not urgent or important. A new request has emerged that requires the team to abandon the work they’ve started and either replan the sprint or use the remainder of the time on new work.
Dependencies:
Dependencies can be either internal or external.
An example of an internal dependency would be a contract held up in your company’s legal department. Or you’re waiting to use a piece of code being written by a different Scrum in another department in the company.
External dependencies tend to be more challenging to resolve since they’re tied to a third party not within the company, such as an API key you’re using or the current software requires an update.
There are so many ways a story can carry over. How do we solve these issues?
Mitigating Overplanning of Story Points:
Getting back to the earlier example of overplanning stories, part of the teams’ retro discussion included asking ourselves these questions:
Did we really have to work on all these stories? I suspect the 50% completed were more important than the 50% that weren’t. As far as I know, nobody has been fired, and the business is still operating.
Was there a way to break apart the story in such a way that most of the value could be obtained by completing only the most important part of the stories?
Were there areas where value was assumed but didn’t materialize? Would there be a way to do just enough (MVP) of the story to prove or disprove the value?
Is the team properly resourced in terms of people, tools, and processes?
This was a great example of a successful retro! The team was in the right place to have the conversation. They were talking about the right things, and we created actionable items that allowed the team to plan better. Long story short, plan more conservatively based on your true velocity trend.
Another reason for overplanning may be the Scrum team is new. A common attribute of new teams is they haven’t figured out their velocity and what it means to commit to a sprint. New teams and low-performing teams usually carry stories from one sprint to the next with little concern. This may also be a reason for overplanning story points.
Our suggestions also include breaking down stories into smaller bite-size chunks (for example, one user story worth 13 story points becomes 2 user stories worth 8 and 5 story points) and setting a story point threshold (for instance, no stories greater than 8 points can be included in a single sprint).
WARNING! What Not to Do
· Don’t create non-valuable work by reverting to old-school project management, micro-management style.
· Don’t point out every little issue.
· Don’t break a single story into dozens of smaller stories.
Allowing for More Discovery Around Unknown Difficulties/Scope:
Sometimes there’s no way to get ahead of an unknown that isn’t discovered until midway through a story or a sprint. It just happens; no amount of pre-planning or breaking up the story would protect the team from the impact.
However, if you are using a new software system, API, etc., and there is some skepticism ahead of the planning exercise, the team can and should use the purpose of a SPIKE. A SPIKE allows the team to use their time for investigative purposes.
WARNING! Spikes can be abused.
The output of a spike is knowledge, such as research and an approach or some sort of prototype (just a different form of knowledge). Either of which—by themselves or without follow-up work—don’t produce much value.
If a sprint is all spikes or your team has a habit of doing a spike each and every time they are uncertain, something is up.
Using Remaining Resources to Tackle the Outstanding Work:
In the case of resource issues and team members being unavailable unexpectedly, at times the team will need to just eat the dip in their velocity and what they can accomplish.
Other options would be descoping the outstanding work, pulling out one or multiple stories, asking for help from another Scrum team that may have more bandwidth (though this can add complications), or seeing if another team member on the Scrum team has more time and capacity than anticipated at the start of the sprint.
Plan Ahead, Be Proactive, and Mitigate Dependencies!
If you know your story has a dependency, whether internal or external, start with that ticket early in the sprint to allow for more time to buffer against the potential issues.
Have a plan for how to escalate the work and get help from stakeholders or people outside the team who have sway.
Be proactive about scheduling assistance from resources either within or outside the scrum team. For example, if you need a meeting with Bob in finance, schedule that meeting with Bob right away. Don’t wait to talk during the last three working days of the sprint!
As a general rule for work that has dependencies, break your stories into the most digestible sizes possible. That way, if the dependency ends up taking three sprints to resolve, you chip away at the smaller pieces you have control over slowly but surely.
For solutions to injections and changes in a sprint goal, see our future articles for more information on managing these common challenges.
Fear not: if your team experiences some or all of these challenges, you are not alone. Rolling user stories from one sprint to another is a common challenge in Scrum. Use team retros to talk about these ideas as possibilities for solving common pain points moving forward, and remember that Scrum is iterative by design. After all, so much learning is done through failure!
Comments