Risk in estimation

Estimates should not be padded. They should be updated to reflect an improved understanding of the scope involved. So if the "best estimate" using the information available at the time of sizing is a 5, it should be recorded as a 5. Should subsequent events during the Sprint indicate that it is more like an 8 then the estimate should be updated at that point.

The Development Team should then take a view of the work on the Sprint Backlog, and the risk that any increased scope represents to the attainment of the Sprint Goal. Any appreciable increase in risk should be communicated to the Product Owner. The whole Scrum Team should then attempt to replan the Sprint Backlog so that the Sprint Goal can still be met.

Some people will suggest "spikes" in this case, but I won't, because the difference between a 5 and an 8 doesn't warrant a spike. (As an aside, I believe in spike tasks, but do not believe in "spike stories"). If you'r issue was the difference between a 5 and a 40, then spike tasks would be a good fit IMO.

With such a small deviation here (5 to an 8), my inclination would either be to:
a) default to the higher one, or
b) flip a coin on whether it's a 5 or 8. Seriously. If you're environment is going to be as complex as you say, than there will be lots of these, and some will be more than estimated, some will be less -- so they will all even out.

A couple of other things I'm sensing here as possibilities:
* Including technical risk as part of the estimate for an item is not "artificially inflating" -- it is buffering for uncertainty, and there's nothing wrong with that, IMO.
* Why do we care so much about velocity being exactly correct? Software dev is a complex matter as you say, and velocity is really nothing more than a planning tool to help forecast release dates for releases that span multiple sprints.

I should also mention that velocity, user stories, and story points are not part of Scrum, but are useful "complementary practices" that can be used with Scrum.

I have a lot of respect for Ian, but I will quibble minorly with this suggestion:

"Should subsequent events during the Sprint indicate that it is more like an 8 then the estimate should be updated at that point."

While this is technically ok/valid from a Scrum perspective, I find it dangerous in practice because it leads to old waterfall habits like estimates/actuals, or a team who doesn't do due diligence to try to create decent estimates because "they can always change it later."

I prefer the approaches I suggested, which are also ok/valid from a Scrum perspective, though I think they fall more in line with Scrum principles or realizing that not everything is exactly predictable in a complex domain, so it's a fool's errand to try for that kind of accuracy.

I think the empirical Scrum thing to do here is, call it a 5 or call it an 8, realize that complexity happens, then retrospect on it later *IF* it's really worth retrospecting on.

So, in short, any of the approaches that Ian, Lindsay, or I suggested are probably ok/valid from a Scrum perspective... the real question is -- which approach works best for the context that you're in?

Posted By Charles Bradley on 03 Sep 2014 03:17 PM
I have a lot of respect for Ian, but I will quibble minorly with this suggestion:

"Should subsequent events during the Sprint indicate that it is more like an 8 then the estimate should be updated at that point."

While this is technically ok/valid from a Scrum perspective, I find it dangerous in practice because it leads to old waterfall habits like estimates/actuals, or a team who doesn't do due diligence to try to create decent estimates because "they can always change it later."

I prefer the approaches I suggested, which are also ok/valid from a Scrum perspective, though I think they fall more in line with Scrum principles or realizing that not everything is exactly predictable in a complex domain, so it's a fool's errand to try for that kind of accuracy.

I think the empirical Scrum thing to do here is, call it a 5 or call it an 8, realize that complexity happens, then retrospect on it later *IF* it's really worth retrospecting on.

Charles, you make an excellent point. We're only really concerned about an *average* velocity...not necessarily an *exact* velocity, so these small differences likely won't change the overall average.

I'm still interested in hearing other feedback, but I think I will recommend to the team that we just accept that these things will happen and we should estimate accordingly ("bake risk in" to the planning/estimation) and retrospect on how to improve, if needed.

I agree that all solutions are OK from a Scrum perspective, just want to add my personal opinion about buffers.
For me they are a classical project management tool to mitigate risks. In Scrum, we mitigate risks by frequent delivery. If we estimate buffers into PBI sizes, and we measure a velocity, this velocity does not only represent what the team got done in a sprint, but also, what it could have done if specific events had happened. But some of them haven't.
From the Scrum guide: "Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned."
So we do not estimate for every risk that could possibly happen, but when it happens, we learn more and react. Inspect and adapt.
Lindsay, my personal choice would be to continue your practice, but ask the team what they prefer.

A team close to me has also a lot of uncertainty. The result is a big ariation of the velocity from sprint to sprint.
But does-it really matter ?
The PO can still compute an average if he wants to, but with a large cone of uncertainty.

If you re-estimate your US from 3pts to 8 pts inside your sprint, you still have the same amount of work remaining in your Product Backlog.
Can your stakeholders just accept the fact that because of the high level of complexity, your estimates are not very accurate ?