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.
I keep coming late into the conversations, so apologies if I repeat points already made.
Honestly, I would take the win, celebrate it, and move on to the next Sprint. Over time, you will have items that are over-estimated and others that are under-estimated, but they tend to balance out. Personally, I prefer estimates that lean slightly conservative. Over-prom]ising and under-delivering, I find, hurts more than the reverse.
Just a note from past experience: I have seen situations where management reprimanded a team for finishing early and called it “bad estimation,” instead of appreciating the commitment and focus that led to finishing early and achieving the Sprint Goal. That kind of reaction breaks morale. Keep the focus on celebrating the success. It strengthens the team far more than trying to perfect estiamtion and velocity data ever could. (By definition estimation can never be fully accurate.)
(If, over the longer term, you notice a consistent pattern of over- or under-estimation, that’s a topic for a retrospective. The team can then discuss whether to be slightly more conservative or optimistic in future estimates — but only based on a clear trend, not a one-off event.)
In the next sprint, we should first inspect the root cause in the retrospective. If our estimates were consistently off, we’ll recalibrate our understanding of story points and ensure all PBIs are well-refined before planning. We can also experiment with alternative methods like T-shirt sizing and hold a short workshop to align on estimation and technical knowledge.
Hi Marco, this question made me reflect on a similar experience we had recently in my team.
While seeing the effectiveness of how accurate estimation and velocity help you forecast better for later sprints — it’s honestly one of the crucial parts of tracking progress regularly on whichever project management tool we are using. At the same time, it builds transparency and confidence in the work we planned for the sprint.
In addition, I agree with Pierre Pienaar — sometimes at the start, during planning, a task can seem complex and effort-heavy based on what we know at that moment. But once we start executing, it can be done really quickly. It simply means that new information emerged and that’s a part of agility. We adapt and learn.
I recently experienced the same within my team. Instead of focusing on the one story point that seemed overestimated, one of our team members completed it really quickly. Instantly, what came to my mind was to celebrate the win and appreciate that we were ahead. It turned out to be very effective — we performed exceptionally well in that sprint, from report creation to stakeholder review. I truly believe it contributed to a healthier and more positive team culture.
And we discussed and learned why it happened. Since it was observed only once, we simply moved forward with it.