Re-estimating cards after they are played seems wrong
One practice that I have observed that seems wrong to me is re-estimating cards after they have been completed. The dev pair completes the story card and the BA comes over and asks them to re-estimate the card based on the implementation.
From the BA’s point of view, s/he is asking for the re-estimation for planing purposes. The reason given is so they can accurately plan out the stories for the next iteration. On this same project, there is also a lot of talk about correctly estimating cards. To me, this completely misses the point of estimating cards.
Story card estimation is a best guess of either the complexity, the story card size, or the ideal days needed to implement the card. That is all. This means that the estimations are inherently wrong. The point though is that they will be consistently wrong and over time, with the addition of velocity, the amount of work a team can get done will be correct.
If a team consistently underestimates, then the first iteration they will do more cards then they committed to. The velocity will show this and can be corrected the next iteration. So the first iteration they commit to doing 12 points and they actually do 15. The next iteration, simply select 15 points worth of story cards. Rinse and repeat.
By asking devs to re-estimate cards once they are completed you are breaking the corrective effect that velocity has on the process. The points on the cards carry less meaning because they have been adjusted after the fact. This means you now need to add a correcting feature into the teams velocity.
The team committed to doing 12 points and completed 15 points, but two of the cards they originally committed to doing were actually 1s and not 3s so did they in fact do 15 points or 19 points? So which cards for the next iteration are going to be re-estimated down and which cards will go up? Does this mean that the team should be doing 15 or 20 points for the next iteration?
My guess for the re-estimation requests is that the BAs do not trust the process. They do not believe that velocity will naturally add the needed correction. So instead, they try to do it themselves. In addition, on this particular project, I also think that business is trying to add to many features during a single iteration and the scope is just too large.
I think there is a time and place for re-estimating a story card, but after the card has been played it not one of them. If, before playing a card, more information becomes available that directly reflects the implementation of a card, that card should be re-estimated. This might include the outcome of a spike or the introduction of a new technology or a change in the development team for instance. The point is that this happens before a card is played, not after.
What do others think, can a story card’s estimate be updated after it has been played?
A card’s estimate cannot be updated after you’ve completed it. That’s not an estimate, it’s an ‘actual’. The implication being that you probably misunderestimated it originally
I’ve seen this happen as an attempt to get ‘better’ at estimating. The idea is that if you estimate ‘build a foobar’ as 2 but it was actually more like a 4, then you want to ensure that all similar tasks (build a barfoo) don’t suffer the same misunderestimation.
Estimates are for planning. What’s the benefit of re-estimating finished work? You’re not getting that time back.
In order to plan effectively, a 2 should take half as long as a 4 and twice as long as a 1. As long as your units are internally consistent it matters not one whit if a 2 takes 5 days or 1 day. The velocity score will let you predict your progress.
What is useful is to periodically reflect on past estimates and look for patterns. So if you find that the team is consistently over or under on certain types of task, you can use that feedback in your planning. Eg. I’ve seen projects where GUI related work was consistently underestimated so any iterations with lots of GUI tasks would reliably fall short of the predicted velocity. Once we realised that GUI work tended to soak up a lot of time we took account so that a 2 point GUI task really did take half as long as a 4 point domain-logic task.
Recording actuals and adjusting story-by-story wrecks velocity as a mechanism for predicting progress because the units of measure are no longer internally consistent.