A common issue among Scrum teams arises when teams consider what to do with stories which are pulled during the sprint but not completed. What do you do with these stories? Should you consider them failed? Should you ignore them and simply continue to work on them in the following sprint? Should you re-estimate them? Should you give partial credit? Maybe they shouldn’t have been started at all? I have tried all of the above and in my experience one particular strategy has shown itself to be more valuable than the others.
First, let’s examine some different approaches.
No credit and rollover
The simplest way to deal with such stories is as follows. Don’t put any limitations on what you can pull towards the end of your sprint. If you can’t finish a story by the end of the sprint, simply bring it to the next sprint’s planning session and continue working on it. Don’t re-estimate, and receive full credit for it when you finally complete it.
It’s simple, and somehow feels natural. The team actually did all that work, what does it matter if it was all completed inside that one artificial time boundary?
Well, as it turns out, if you are doing Scrum, there are several reasons why it matters. Allowing stories to roll over into following sprints sends a strong message that the sprint boundary is not very important. If the sprint boundary is not so important, then the sprint commitment is also less important. Couple this with the natural tendency for team members to locally optimize by choosing the stories where they can have the most impact, and you have a situation which basically breeds individualism and serves as an extreme detriment to team focus towards a common sprint goal. This in turn inhibits the spread of information and knowledge, and also directly affects code quality. Of course it is possible to have both (rollover and team focus), but the roll over policy does nothing to help strengthen team focus, and in most cases actually works against it. So having both requires a pre-existing understanding of the principles and a high level of team discipline.
One of the results of this solution is that whenever a story is carried over, you will see a dip in velocity in the previous sprint and a spike in the next sprint. The size of this variance is directly related to the size and number of stories carried over. If a story of 3 is carried over, you will see a variance of +-3. However if 2 stories of size 8 are carried over, you would see a variance of +-16. If the overall velocity of the team is 20, then this is quite a big difference, the previous sprint has a velocity of 4 and the next sprint has a velocity of 36. The main argument here as I understand it, is one put forward by Mike Cohn here. In his description, velocity is a planning measure, not a sprint level measure, and so the fluctuation between individual sprints are less important than the average rolling velocity. I can understand this argument, but in my experience, such wildly fluctuating velocity can do several other negative things. It can hide other problems which might be noticed by fluctuating velocity, it can reduce confidence in velocity as a metric, and it can negatively affect team morale. Coupled with the problems mentioned above regarding sprint commitment and team focus, the net result for me is that I would not recommend this approach.
Partial credit
Another relatively simple way to deal with such stories is to give the team credit for the part of the story which is complete.
This also feels somehow fair to most teams. We’ve done that work, and if you don’t want us to roll it over into the next sprint, can’t we just measure what we completed now and count it as velocity?
Again, if you are doing Scrum, there are several reasons why you shouldn’t do this. Allowing partial credit discourages clear story breakdown and provides a potentially seriously wrong view of progress. People are notoriously bad at estimating how much of a task is complete, both as a general bias, but also because they are optimistic and want to show positive progress. Every team has multiple experiences of the perpetually “almost done” stories and tasks. A story is either done or not done. Please strike “almost done” from your team vocabulary. Even if you could correctly estimate how much of a story has been complete, it is very unlikely that the completed part of the story fulfils your team’s Definition of Done.
What if you are able to split the story at the end of the sprint in such a way that you can actually deliver a subset of the acceptance criteria which fulfil your team’s Definition of Done? Should you then get the credit for the completed part and postpone the incomplete part to next sprint with a new estimate? Maybe. Ask yourself why you didn’t see this possible split in your story during your sprint planning. Could you have seen it earlier, and is the current split just a scramble to make sure that your velocity looks good and your team doesn’t feel bad? Be honest with yourself. If you think you should have been able to see the split earlier, then don’t allow the partial credit and figure out some improvement to catch such issues earlier in the sprint (preferably during planning). Allowing partial credit here severely discourages the practice of splitting stories into small and manageable chunks early on, and also discourages reduction of dependencies among stories, as a team could simply claim to have completed “their part” and push the responsibility for full completion over to the dependent team.
Note that working in such a way with such strict rules is essentially a way to condition yourselves to focus in on a certain principle. If you just follow such rules blindly without understanding and discussing why, then you will not learn anything and will only create frustration.
No credit and re-estimate
This solution implies that no matter how much work you did on your story in the previous sprint, if you did not finish it, the work does not count towards your velocity. It takes the view that velocity is a measure of how much you can deliver in a specific time frame.
This is the solution which rings most true for me.
It encourages splitting stories into very small and independent chunks, because the smaller the bits are, the less likely the are to extend past the sprint boundary, and the more freedom individual team members have to pull new stories towards the end of the sprint.
It encourages team focus and swarming, by pushing team members to try to help current stories instead of pulling new stories at the end of the sprint. The story most likely to deliver velocity for the team is one where a colleague is almost done, not a new story.
It supports the environment for knowledge transfer and common code ownership and discourages siloing, by pushing team members to help with current stories and follow the business priority instead of just jumping on the next story which fits their expertise.
It gives a much clearer indication of how much a team can actually deliver during a specific time frame, by only giving credit to fully delivered work.
Taking all of this together, the net effect is that this solution guides teams in the direction of product flow, as described in Lean literature and also as described by Don Reinertsen, here.
Ulas
Great post; I definitely agree with you. Two observations from my experience. The first is that writing good (i.e. small and with easily testable acceptance criteria) stories is a prerequisite for your recommended approach. When a team starts moving in the direction of no-points-and-reestimate, the first priority should be working on good stories. The second thing is that teams are very aversive of going over old stories, looking at whether they were estimated right, and whether they could have been split into smaller bits. This is probably because noone wants to talk about stuff that’s “done”. A software team spends hours every sprint cycle talking about the sprint and the work that is coming up; piling even more hours on top of this to talk about old stuff is very difficult to sell.
Discipline on these two points really pays out, though.
Freyr Guðmundsson
Hi Ulas,
thanks!
Writing good stories – independent, small etc – is absolutely necessary yes, but I think the approach of doing no credit and re-estimating stories would actually encourage teams to move more in the direction of writing good stories. So hopefully this would form a positive feedback loop, while other approaches can easily form negative feedback loops. Often you need a jolt to get out of a bad pattern, and I think that setting a hard rule such as the one described above could be that jolt.
The extra benefit of doing it in this order is that it helps you define what is a good story. Just jumping in and trying to create “good” stories is often overwhelming for young teams. What is good? How do I know what is good? If you have the rule above that you just don’t get credit for stories that you don’t finish, then you are automatically pushed very forcefully in a certain direction. The obvious first response is make stories smaller. Then you’ll have conversations about how to slice stories, how to make them independent, and whether you can have technical stories or slice by component. All of which are very important conversations for teams to have, and might not happen organically.
As for looking at older stories, for sure, it’s tough to justify that cost. And to be honest, I’d prioritize that lower than many other things. In the examples taken above, I would consider the most important part simply the realization that stories should be smaller. Then a team can assess for itself whether it feels like it can do a post mortem on a particular story to learn how they could have split it better. This would be great, but it is also fine to just take the next big story that comes up and simply practice breaking it down. One possible approach could be to decide on a single specific way you will try things differently this sprint and then assess at the end. An example could be the following:
– You failed at an 8 point story last sprint
– Next sprint you have a new 8 point story
– You can’t figure out a way to split it by value, so you decide to split it into frontend and backend
– You run the sprint, observe the results and verify or falsify your hypotheses (which is that splitting by front/back end would allow you to deliver value more regularly and with more certainty).
In this case, it is likely that the hypothesis is falsified, but ideally you would learn something from it. Arguably such focused learning is more valuable than just doing something without a hypothesis and then retrospecting on it after the fact.
Ulas
Interesting, so you would say that iterating on different options and seeing what works is more valuable than inspecting past stories and processes. Makes sense. What would you say about the length of sprints? I always found shorter sprints to be better planable, because they also force you to write smaller and better stories. Wouldn’t “iterate more often” speak for shorter sprints, too?
Freyr Guðmundsson
If you start out with a hypothesis, try it out and see how well it works, what you actually end up doing is inspecting the results of the sprint, but with a specific focus instead of the classic “blue skies” retrospective. So you actually get the best of both worlds.
And yes, shorter sprints are easier to plan, push you further in the direction of story discipline, and allow you to learn and adapt faster. But the shorter the sprint the more focus and discipline you need to be constantly on the ball, watching your progress, your hypotheses, inspecting, adapting, changing…it can easily become exhausting. Even though you make sure to timebox your overhead to be a % of total time (e.g. 1 hour planning per week of sprint), there is always a lower limit where the effort of just getting into the mindset of the next meeting outweighs the benefit of the meeting. A one day sprint with a sprint planning of 8.5 minutes is pretty hardcore.
Conversely, you could make the case that some experiments definitely need more than just 1 week to verify, so too short iterations could damage the inspect and adapt cycle.
I think best would be to separate the hypothesis process from the sprint length when possible. Some examples are just tied directly to the timebox (e.g. the example in my previous post with experimenting with how to break down stories), but many other possible improvements are not. Some cases might need weeks to gel, and in others you could run an experiment just for one day, or even for one meeting and decide on the spot whether it worked or not. This is often done in the Kanban world, where they don’t run a retrospective, they run impromptu improvement sessions as soon as a potential for improvement shows itself.