We want to build to a DONE culture where teams strive to get every Story DONE, every Sprint.
Taking a relaxed attitude to finishing Stories in the following Sprint doesn’t help set the expectation that DONE is something to strive for.
Partly DONE Stories can lead to an test heavy plan in future Sprints as developers code right up until the end of the Sprint instead of swarming on the Stories the team have already committed to and getting them DONE.
Not DONE Stories are wasteful.
Like it or not, Team’s often equate SP to credit. They often ask, “how do I get my points (credit)”? By letting Team’s take their credit/SP in the following Sprint it sends the wrong message about working towards DONE. Only giving SP/credit for DONE Stories incentivises teams to think about getting Stories DONE if they want the SP/credit.
Team’s velocities are calculated by summing all of the DONE SP and dividing by the number of Sprints. This leads to a slight overestimation of what the team can actually get DONE as it includes SP that got done and SP that the team could not get done. Overestimation leads to over-planning and this has costs associated with it:
- Unsustainable pace https://www.benlinders.com/2013/working-in-a-sustainable-pace/
- Quality decreases
- Technical debt
- Team morale damage
- Cultural damage
- Staff turnover
- Onboarding new people takes a lot of effort and impacts the amount of value the team can deliver
Striving to complete the Sprint backlog that the team committed to in Sprint Planning encourages the team to master core Scrum practices that will help the Team get their Stories DONE eg
- Story writing
- Cross functional behaviours eg developers testing
- Actively talking about how to get all of the Stories to DONE
- Scrum ceremonies
Teams need to do some sort of re-estimation of any partially completed Stories so they know how many SP are left for new Stories in the coming Sprint. If some sort of re-estimation of remaining work isn’t completed then there is a risk that the team will be over-planned.
Quick and informal re-estimation of Stories that didn’t get DONE eg by the dev who is working on a Story, are likely to be less accurate than a formal re-estimation process eg whole team and planning poker.
If you are re-estimating anyway, why not update the Stories in the next Sprint with the more accurate numbers?
If a team re-estimates SP but doesn’t update the Stories then only insiders in the team with the secret estimates can accurately read boards, Sprint Burnup/Burndown.
If Stories aren’t updated it makes it difficult for outsiders (RTE, PM, Sponsors etc) to assess how the Sprint is progressing by looking at boards and in tools like JIRA eg if an 8SP Story
hasn’t been started with 3 days to go on a Sprint, is that a problem or not?
If Stories aren’t updated with the new estimates then it can be difficult to interpret reports like burndown charts eg how did the team get a 5SP Story done on day one of the sprint? If the 5SP being burnt on the first day obviously isn’t an accurate representation of effort expended then how can we trust any of the other changes in the Spring Burndown Chart.
Sprint plans with accurate, re-estimated Stories are more honest and transparent. Because of this, better decisions can be made.