We’ve been coaching a few new teams to use Scrum and it’s interesting to see the similarities continue to pop-up, particularly around estimating how much the team can complete in a Sprint, and then what to do when a Product Backlog Item (User Story) doesn’t get completed. So what do you do when the User Story gets more complicated half-way through and, as a result, can’t be completed in the Sprint?
What are Story Points?
Story Points are a size categorisation system. They’re not part of Scrum, but many agile teams find it a useful way to have conversations about the complexity and time needed to deliver work.
Story Points are:
- A proxy for the amount of effort it takes to get a Product Backlog Item to Done. The bigger the size category the more effort is required by the team to get the item to Done.
- Not directly related to hours of effort or days. They’re not “effort points”.
- Not used for tasks, only the User Story.
When a User Story meets the Definition of Done, then the Story Points are added to the team’s velocity.
A team’s velocity is the average amount of Product Backlog that can be turned into a potentially releasable Increment. It’s not a measure of effort the team has put into a Sprint.
1. Put it back into the Product Backlog
A User Story doesn’t get allocated to the next Sprint or “rolled over” if it’s not Done. It simply returns to the Product Backlog. From there, the Product Owner will assess whether it’s still of business value to complete and will order it accordingly. The Product Owner may or may not decide to put it into a future Sprint.
2. Don’t add the Story Points to the velocity
As the User Story did not meet the Definition of Done, the team doesn’t gain any of the Story Points and no part is added to the team’s velocity.
Some suggest that the team should get “partial-credit” for their efforts, but this gives a false sense of what the team can actually get to Done in a single Sprint.
3. Re-estimate the remainder of the User Story needed to get the item to Done
When it comes time for Sprint Planning, the Team should then re-estimate the remainder of User Story based on:
- Why the User Story didn’t get to Done.
- The new things they’ve learned about the User Story.
- The new tasks and/or requirements of the User Story.
- The remaining work only, not the whole story including what was Done.
4. Have a conversation in the Retrospective about why the item didn’t get to Done
At the beginning of the Sprint, it was obvious that the team felt they could get the work to Done, only to find out that by the end of the Sprint there was still work remaining to do. Why was this? What made the team underestimate the work needed? Doing a postmortem is critical to ensuring that this doesn’t happen again in the future and that estimations are accurate.
Conclusions
Understanding the relationship between Done and estimation helps team improve its forecast of what it can realistically achieve each Sprint and how much of the Product Backlog it can turn into a potentially releasable Increment. Better estimations empower the Product Owner to better forecast what can be delivered when, making for more satisfied stakeholders and improved satisfaction amongst customers.
M
