How to handle a backlog item where the estimation is extemely off at the end (expect weeks, done in 30 min)
Context
In my teams, we've been using Planning Poker for over a year now, and it's worked well for what we want to achieve. We use the standard (1, 2, 3, 5, 8, 13...) to estimate each work item before the sprint starts. We have establish a previous sprints average velocity that we use (for example, 39 points). We then use that average, along with contextual factors (e.g., “John is on vacation this sprint, so let’s aim lower than 39”), to guide what (how many pts) we include in the new sprint initially..
So far, so good. Estimation errors happen occasionally, but they tend to balance out over time ( a 8 might be completed faster, a 3 might take longer. Overall, it averages out enough for our need.)
However, we recently estimated a work item at 8 points (we don’t directly link points to time, but for the sake of argument, let’s say it was perceived as a big week of work, more that one person, etc.). This time, the high estimate was due to uncertainty and the need for research.
But once we started working on it — boom! A solution was found and applied quickly. Total time: under one hour.
Now, someone on the team rightly pointed out that leaving this item at 8 points will impact our velocity average for several sprints. On the other hand, retroactively adjusting estimates opens a can of worms.
So here’s the question: What’s a good way to handle this kind of situation? Any suggestions?
I am tempted to « tought it » like that and point out at the next 3-4 sprints that the velocity is slightly high vs reality, since velocity is just a tool...
You're already taking contextual factors into account, such as your example of someone being on vacation. Why not just remember that there was a significant over (or under) estimation for a couple of Sprints and then move on? You don't need to invest any time in conversations about what the size should have been and can focus on planning your next Sprint.
So here’s the question: What’s a good way to handle this kind of situation? Any suggestions?
Assuming the work is Done, it's already handled. The estimate is over, finished, done with, spent. Learn anything there might be to learn about how to improve future estimation techniques, and move on.
My teams never adjust past estimates. We keep them as they are, and use the experience to improve how you handle uncertainty in future refinements. Remember, velocity is a guide, not a goal.
Velocity is an indicator that should not prevent you from thinking for yourself.
Some of our teams use velocity as a starting point for planning and then consider whether they can plan more or need to plan less.
So in general, nothing has to be adjusted.
How significant is this fluctuation? Does it really make planning more difficult? In most cases, it does not.
If your velocity fluctuates too much in general, you could change the calculation method (e.g. include more sprints in a moving average). This means that the outlier is included for longer but has less of an impact.
However, this would mean that an actual change in velocity would take longer to be reflected. This is another factor that needs to be balanced.