Skip to main content

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.

 


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.