Re-estimate or not?

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.

Splitting

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.

Do re-estimate.

4 thoughts on “Re-estimate or not?”

    • Basic rule here is that as long as scope of work didn;t change – you shouldn’t re-estimate. Surely the estimation during the sprint might seem inaccurate but this is the place when velocity comes in a way.

      Re-estimation:
      – stories already in sprint – don’t
      – stories in backlog – do

      Reply
      • This is a good example how things should work in theory, but in reality… Points in the system are often used to estimate future tasks.

        “This task is the same as that one, so it should also be 5 points”. We often use this pattern on the grooming meetings; the only problem “that task” in reality was 10 points. We created some “false” assumption long ago and used it in the future.

        Agile is not a lists of rules that everyone must follow, it’s a list of recommendations that describes a methodology. It’s pretty flexible actually and commands like “stories already in sprint – don’t” are usually more harmful, than useful, because they kill agile idea, resulting in “one can’t see trees for the forest”.

        Reply
        • Alexey Kruchinin I mostly agree with what you said. The reason why I do not recommend to re-estimate during the sprint if the scope didn’t change is simple. From my experience teams tend to reestimate in order to fit their built expectation of how many points should be burned per day (so if the task took longer – they reestimate, but in fact, they should keep estimation and just lower the capacity next sprint).

          Reply

Leave a Comment