Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Change task estimation during the sprint

Last post 07:28 pm February 7, 2022 by Jaya Agnihotri
5 replies
10:54 am February 6, 2022

Hello,

I share with you a case that has happened recently in a scrum team.

The sprint lasts 2 weeks.
One of the technical tasks (not user story) was estimated in 8 story points.

The team member who performed the task reported that the task had taken more effort than estimated, claiming that before the end of the sprint he wanted to update the estimate from 8 to 13 points to reflect his extra work effort.
And that he considered that the scope of the task had changed.

What do you think?

Thank you very much.
Best regards,

 


11:23 am February 6, 2022

I think that the Developers ought to estimate their work collectively, and keep those estimates updated so a backlog always tells the truth about how much work is believed to remain.


05:23 pm February 6, 2022

It sounds like the work is done. What would the value in changing the estimate be? Consider that if you change this estimate, the team will probably want to adjust every estimate in the future, whether it's up to account for more work or down to account for work that took less effort than expected. Would having these discussions and taking the time to update these estimates add value to anyone?


01:07 pm February 7, 2022

The reason we have Fibonocci series(like) for storypoints is that when the complexity is high it is difficult to asses the estimation closely. Moreover it is used for relative estimation and not accurate effort of what it takes to complete a task.So why not the extra effort could still be 8 ?. Increasing it to 13 is like adding a new 5 sp task to old task. I would ask why the change in scope in not taken as a new task ?

 


05:39 pm February 7, 2022

What benefit would be gained by changing the estimate?  An estimate is made based upon information known at the time of the estimate. It is used to help the Developers make a judgement call on whether the work they want to do in a Sprint could be accomplished.  Once work begins, that estimate is worthless.  

It sounds like your organization "gives credit" to Developers for the amount of points they complete.  This is a perfect example of what happens when you have that practice.  Estimates start to become larger and people want to make sure that they "get credit for all of the work they do." You organization has even gone to the level of estimating tasks with Story Points.  If they were meant to be used at the task level they would have been called Task Points. 

My opinion is that you are misusing the practice and are now seeing the consequences of it.  


07:28 pm February 7, 2022

Story point is for relative estimation. In case a change is identified and required to be completed to mark existing task as done/complete, team can create a new task/sub-task, estimate it, plan it and develop and deliver it.

Make sure SM will discuss this item in retrospective, so that team will evolve further in its Agile journey.

Going back and changing existing task estimate is like - following waterfall model, where accuracy of estimate matters , and accuracy of documentation is maintained for future reference. Agile way do it differently, add a new task/subtask, discuss this matter in retrospective for future improvement of teams estimation/planning practices.