Re-estimate?

During the SUM, a team member asked if we can re-estimate the storie because more time was spent on it than estimated during the refinment. What is the best thing to do when it comes to velocity?

@Merette Warnaar, What is SUM?

What purpose would it serve if you re-estimate?

Could you also elaborate what you mean by the best thing to do when it comes to velocity?

Merette,

Why do you believe the team member wants to adjust the story estimate so that it more accurately represents the effort spent?

It is important to remember that estimates are only used for planning purposes - there is little benefit to adjusting them after the work is done.

To use an analogy, I would be a dead-eye archer if I was allowed to move the target to where I shot the arrow every time.

Think about how adjusting an estimate after the fact can reduce transparency and hinder a team's ability to inspect and adapt.

Merette, this is a good question.



Although I am not sure what you mean by "SUM", I can offer my opinion in general. I think the correct answer is -- it depends.

Specifically, what reasons could be uncovered for why the Item might have taken longer than estimated?   

• In general, if additional scope, acceptance criteria, etc. was added to the Item after the original estimation, it should be re-estimated.
• In general, if the Item simply took longer than the original estimation, that is okay, and it should not be re-estimated.

The goal with velocity is to find consistency. Consider this -- if the Development Team consistently estimates some items correctly and some items incorrectly, there is consistency in that. If you were to retroactively adjust an estimation to align with the actual time spent, you would be undermining accuracy in Velocity.

To go further, I would recommend looking into your estimation techniques. Although this isn't "Scrum", some estimation rules I follow, my "estimation manifesto":

1. Relative Sizing of Level of Effort OVER Time Estimates
   • Generally this is referred to as "Scoring" and usually uses the Fibbonnaci Sequence.
     • As an example, if you have a desk and a chair, it is easy to see at a glance that the desk is larger than the chair (relative comparison). However, if I asked you, "just by looking at either object, can you tell me to the inch/cm how long either is?" -- your answer will probably not be correct to the inch/cm (specific estimate). Once you establish how long Item #1 took to complete, if you know that Item #2 feels 3x larger than the original, that will provide a forecast into how long the Item #2 will take (~3x longer), and so on with other Items that have been relatively compared to other Items.
2. Time Range Estimates OVER Specific Time Estimates  
   • (Use if you have to estimate in time and cannot use Relative Sizing of Level of Effort)
   • If I try to estimate to a specific time (example. 3 hours), I am probably attempting to be more accurate than I can realistically be to that precision.
     • Think about weighing an object on a scale. If I have a scale that is only precise to the nearest .1 gram, I cannot use that scale to weigh something to the nearest .01 gram. If the object's weight is actually .05 gram, the highest accuracy read I could provide from that scale would be between .0 gram - .1 gram for that object. So it is likely more accurate to say something would take 2-4 hours than to say 3 hours. Although the range is LESS precise, it is likely MORE accurate.
   • The higher the unknowns, risks, etc., the wider the range.
3. Forecast OVER Estimate
   • Forecasts are the best we can do at any given time with the knowledge and data we currently have. They sometimes do not hold true.
   • Even the word forecast brings a different mindset than the word estimate. Think about a car repair estimate versus a weather forecast. This will also help with setting expectations for what is realistic in the unknowns for software development.

During the SUM, a team member asked if we can re-estimate the storie because more time was spent on it than estimated during the refinment. What is the best thing to do when it comes to velocity?

Would this re-estimation help the team to more accurately forecast the amount of work that remains for the Sprint?

The only value of re-estimating that I can reasonably assume is if the team is being judged based on the units of estimation they complete. This really sounds as if the Developer feels that they are being judged by that criteria, not based on the quality and value of the work they undertake.  That would be the issue I tried to address. 

As @Timothy Baffa did, I'm also going to use an analogy.  I am cooking dinner for my family. My son asks me how long it is going to take so he can decide if he has time to do an exercise routine. I tell him 1 hour. He decides to exercise as his routine is 1 hour.  I finish in 45 minutes.  Would there be any benefit to my re-estimating? This is an opposite case than you state but an incorrect estimate is an incorrect estimate.  But by definition there is no such thing as an incorrect estimate if done based on the information you have at the time of making the estimate.

Merriam-Webster defines an estimate as:

a: to judge tentatively or approximately the value, worth, or significance of

b: to determine roughly the size, extent, or nature of

c: to produce a statement of the approximate cost of

What your developer is asking to do is change the estimate of work to recording the actual work that is done. That would only be a benefit if the Development Team encounters exactly the same story and nothing has changed in the code base since the original story was encountered. And then it will only provide another data point in the estimation because you would expect that they learned from it previously and should be less effort associated at to the discovery of the right solution. 

Once work starts on something that has been estimated, the estimate is history and you can not change history.

I'm going to add onto these analogies a little bit because I feel that it's what you do with the new information that can be important especially when there's stakeholders involved. 

Using Daniels dinner example, if my original estimate was 1 hour I may realize about 30 minutes in that the cook time will actually be closer to 45 minutes. I can choose to communicate this new learning to my son who is doing a 1 hour workout so that he can now decide if he wants to a) cut his workout short to eat dinner or b) continue on with his workout as planned. 

On the opposite end, if dinner was running late the new estimate may be useful to my son because he may have time to do some extra sets or take a shower prior to dinner. It comes down to how much I care that he's at the dinner table when it's ready or how much he cares to eat the food fresh. Either way I could use this new learning when making this dish in the future.

---------------------------------------

Similar  analogy - If I'm meeting a friend for coffee and I estimate 20 minutes to get to the shop but I encounter a ton of road construction I didn't know about then all of a sudden my estimate goes to an hour. It may be useful to communicate the new estimate to my friend so we can decide how to handle the situation.  

Thank you all for your answers! This really helped me.

Hello, 

I have a follow up question on this. In my teams, we are encouraged to resize stories if needed within the sprint (before closing the sprint) because it captures the extra effort spend on an item. The reason why we are encouraged to do this is because it will then give you a more accurate velocity and help predict how much work the team can actually do. It helps me a lot during sprint planning, because the average velocity becomes more and more accurate when the team resizes and at the end there were times that the team's velocity did not change at all and it reflected exactly how much the team could deliver. Of course it is not something that happens often and when it does happen then we have a discussion at our retro.

What are your thoughts on this? I would really like some ideas/suggestions. 

Thank you.

The reason why we are encouraged to do this is because it will then give you a more accurate velocity and help predict how much work the team can actually do.

To refer to my archer analogy at the beginning of the thread, moving/adjusting the target/estimate may improve my results, but does it help me become better at hitting a target (estimating)?   

How can I improve my accuracy as an archer if I'm allowed to move the target after I shoot?

How can the team improve their ability to estimate if they are allowed to adjust their estimates after the fact?

Be very cautious with this practice, as it seems to permit open "gaming" of story points completed.   I am curious if this practice is truly intended to improve velocity "accuracy", or whether it is intended to help the team look better if output-based metrics are being used to measure the Development Team.

It helps me a lot during sprint planning, because the average velocity becomes more and more accurate

Of course it is not something that happens often and when it does happen then we have a discussion at our retro.a

This sounds healthy. It seems as though you understand that the most helpful purpose of velocity would be to assist in planning for a sprint. It also seems that as an unusual action, it triggers further inspection in a Sprint Retrospective.

Timothy is right that velocity can be an output-based metric, that is used to measure the team, and how that can be abused. In my experience, if velocity is shared outside of the Scrum Team, it usually does more harm than good, and it can undermine any of the advice you receive here about estimation.

Empirical decision making relies on transparency. In this case, it seems to be a trade off between what was the original estimate (at the start of the sprint), and what is the estimate once more is learned. They can both offer transparency over different things.

Sometimes it is more transparent to just use original estimates in your velocity, as when you next come to a Sprint Planning, you only have original estimates for the upcoming backlog items.

Perhaps the team would find it more helpful to measure velocity based solely on the original estimates, and separately keep track of perceived inaccuracies in those estimates.

For instance, if they find there's an average perceived inaccuracy of 5 points per sprint, they could aim to get better at estimation until that number is low enough to not be a problem.

Again, this metric about perceived inaccuracy should also NOT be used outside of the Scrum Team as a performance metric.

I have a follow up question on this. In my teams, we are encouraged to resize stories if needed within the sprint (before closing the sprint) because it captures the extra effort spend on an item. The reason why we are encouraged to do this is because it will then give you a more accurate velocity and help predict how much work the team can actually do. 

I will echo what @Timothy mentioned ( nice analogy) . By definition Estimates itself means a best guess. What at the end Estimates brings out is more important to know - A number ? a size ? more clear task ? better insights ? Even if it does all at the end it still remains the best guess. More is known when the actual work is started. If team overestimate then what stops team to pull in more tasks ? If team underestimate then what stops team to make it transparent and inspect on the progress towards goal ? Whatever is the output becomes a part of team learning. How about a football game where team predicts how much they can score to win a game. But when they start playing only then they realize the reality. What is more important here for a team - to keep changing the prediction they made before the start of the game? or re-group whenever needed and try to win the game with whatever margin they can manage.