All Scrum Teams aim to deliver all of the things they committed to deliver. But because of some circumstances, every team occasionally overestimate their capabilities. They might still deliver The Sprint Goal without all tasks inside the sprint or even worse – they might fail with delivering The Sprint Goal. In either case, the spillovers (tasks that are started but not done) are the problem.
It is common to see developers hesitation to re-estimate as they feel that part of their work is missing somewhere between sprints. I would like to shortly describe three common approaches: Reestimating, Splitting and Not Reestimating.
In this scenario the development team is splitting unfinished stories or tasks into smallers pieces and assign partial estimates to them. It is not ideal solution since:
- the team is learning that partially done stories are still acceptable,
- the team is probably assigning points to things that separately give no value for the end user,
- whole team is approving things that wouldn’t met the Definition of Done at the beginning of The Sprint.
In result, the calculated velocity of such team will be higher than it really is and more importantly, the team won’t be able to determine when what stories should be finished.
While splitting tasks post factum is not a good thing to do it is still preferably approach during the Planning and later during the Sprint. Ideally as soon as possible, when Development Team signalize that they won’t be able to deliver all stories they committed to.
So should we leave the estimate?
We came to conclusion to not partially accept the stories. So what we should do now? We know that we need to put it back in the Backlog. The moment we agreed that splitting stories at the end of the Sprint is not the best solution we were being left with only one question. Either we reestimate remaining work or not?
We need to understand it, and I am very particular with my words, we are not getting paid for Story Points we deliver.
Story Points were invented to help us estimate and predict the future. For instance, we can try to estimate release date simply by calculating summary of all Product Backlog Items and dividing it by team’s velocity. The closer Product Backlog mirror reality the more accurate the estimate will be. Keeping in the Backlog stories estimated for more Points, when we know that remaining work is way smaller is harming ourselves.
Having that in mind we are going to have no further problems with answering title question.