Scrum Project Estimation Beyond the Near-Term?

by Dan Puckett on Jan 03, 2011 |

Michael Sync has a question about how to estimate large projects or large features:

I heard that we should not estimate more than one or two sprints because we will have to change them later. But it doesn't really work in reality. We need to estimate the whole project or a few features in advance so we can negotiate the target date and adjust/prioritize the features. In order to estimate more accurately, we need to break down the user story into the task before creating the sprint. How should I handle or estimate for that?

Peter Bell makes an important distinction between estimates and commitments:

Are you being asked for estimates or for commitments? An estimate is an educated guess based on the information currently available. Estimates are always either high or low, and usually low when building complex software. They are not commitments and can't be used as commitments.

The consensus of the Scrum Development mailing list seems to be that project effort estimation isn't a particularly useful activity, or one that you should spend a lot of time doing. "woynam" writes:

Organizations that really get this stuff stop worrying about how much something is going to cost, and shift toward variable scope work. If you know how much you are willing to spend, and how much time you're willing to invest, then the only variable is how many prioritized features you'll get for your money. The key is that if you are "off" on your estimates, you're still guaranteed to get the most valuable features first.

George Dinwiddie writes:

If your profit or loss is dependent on a precise, accurate prediction of the cost, then you've chosen the wrong product. The upside potential is too small.
Often I find that the people on the top of an organization understand this, but the managers in the middle often do not.

Ron Jeffries expresses the strongest view on the matter:

Estimates are not a good thing in most organizations: they are used as commitments and bludgeons. They also lead to a mechanistic approach to deciding how much work to take on, adding up points or hours, rather than a deeper look at what the team can accomplish, and how.
[...]

I recommend not estimating stories at all, beyond making them all "a couple of days work for a couple of people". That is, of course, still a kind of estimate, but not one that is easy to misuse.

[...]

I like having the team estimate the big stories in weeks, then add them up. What this will do is give a general sense of the size of the project. THIS CANNOT BE A PROMISE, but it can be a point at with you can ask the important question, which is something like: With N dollars and M months, can we get something worth shipping?

Related Editorial

Agile workshops and training

Speed Matters: See why Nike, Groupon, and Comcast are using New Relic

Infographic: Just How Big is the Nerd Economy

Application Performance Management Buyer's Guide

Enterprise-class API Patterns for Cloud & Mobile

Related Sponsor

Agile Project Management That Adapts With You. Provide your global development team a shared space that adapts to the way they work.

Hello stranger!

You need to Register an InfoQ account or to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Community comments

I agree with Ron by Chris Matts Posted

Re: I agree with Ron by Asael Sepulveda Posted

More detail doesn't lead to better estimates by Sebastian Kübeck Posted

Not estimating stories??? by Dick Carlson Posted

A recurring question by Dave Nicolette Posted

Enterprise adoption challenges for Agile by Rajesh Raheja Posted

I agree with Ron by Chris Matts

I agree with Ron. Detailed estimates give a misleading level of accuracy. I prefer Karl Scotland's T-Shirt Sizing ( S - 1 day-ish, M - 2/3 Days, L - 5 Days, XL - Needs breaking down ).

Of course the biggest problem with estimates is that they give an estimate of effort rather than elapsed time. (Which is where velocity comes in I suppose.) The business investor wants to know about elapsed time ( times run rate ) which gives the true cost.

More detail doesn't lead to better estimates by Sebastian Kübeck

I think the problem is that even if you plan in more detail for a longer period of time, you don't get better estimates. This is due to the fact that software development is an indeterministic process. There is a natural limit to what can be estimated with some accuracy and the estimates get worse for longer periods of time.
This is independent of the process (Scrum, XP, Waterfall, etc.) you are using.

That's a bit like the weather forecast: It works pretty well for the next few hours. It gets far worse for the next few days and it's completely unpredictable what the weather will be like in two weeks from now (with the premise that you don't live in the desert or at some place where the weather hardly ever changes).

So you have to accept that you get bad estimates. Sometimes it helps to compare projects with previous projects. Sometimes it is better to have a more or less fixed
budget and you do your best to squeeze in the most important features.

It's a bit like Heisenberg's uncertainty principle. There is a natural limit for estimates and you cannot get beyond it.

Re: I agree with Ron by Asael Sepulveda

You can to split the project so that the first release is short (and therefore less risky to estimate and commit) and then, based on the velocity you could make a moré solid estimation for release 2, and so on.

Not estimating stories??? by Dick Carlson

While I agree with Ron that estimates are typically interpreted as commitments by converting them into days or hours, PBIs must be estimated. I still prefer to use nebulous story points for initial product backlog estimating to avoid the interpretation of time (and thus commitment) by traditional thinkers. Many customers, especially DoD customers, expect to know "exactly" how much work is planned and how long it will take. They also need this info to load their earned value system, so we cannot avoid estimating all features, epics, and stories. The challenge is to pull everyone together during Iteration Zero (or pre-planning activities), including program/project management, product owner, team, SMEs, domain experts, and other key stakeholders (that may also include the customer) to agree on the size or complexity of each item, and then determining how much of the most valued and dependent items can or must be completed within the customer's schedule. When this decided, we have a collaborative agreement and an excellent segue into the creation of a product roadmap and release plan that aligns with the customer's milestone review strategy. When our DoD customers are involved in this level of planning, they begin to see the real value of a lighter approach to the waterfall model - something that will take years of practice and change.

A recurring question by Dave Nicolette

This question comes up from time to time, and when it does I'm always surprised. Maybe I shouldn't be.

I think there are two obvious points here (but I may be wrong about the "obvious" part):

(1) Macro-level estimation with the goal of making a go / no-go decision about an entire initiative or about a major release is necessary and useful. Scrum does not address this at all. There are other disciplines that address it.

(2) Micro-level estimation of individual work items or tasks or User Stories is a complete waste of time. If a team isn't (yet) skilled enough at splitting stories to arrive at a reasonably consistent story size, then they may use relative sizing at the sprint planning level (like T-shirt sizes or a Fibonacci scale). This is an interim technique that keeps the work moving until the team learns to craft stories more skilfully.

"Reasonably consistent story size" means (IMHO) that the variation in size is smaller than the natural variation of fine-grained task estimates. That implies the variation in size is not significant enough to have an impact on short-term planning. Short-term planning doesn't have to be dead-on accurate. It only has to keep the work on track.

I suspect this question keeps coming up because people don't recognize the difference between these two levels of estimation and their distinct purposes.

When people say "Scrum doesn't say to do this" (or other statements with a similar structure), it strikes me that they are trying to adhere to a model (in this case, Scrum) too rigidly. The fact Scrum doesn't deal with macro-level estimation doesn't mean a Scrum team is "not allowed" to do any macro-level estimation. Yet, people seem to be afraid to do anything their chosen model doesn't explicitly define for them.

Sometimes I call this behavior Camelot Syndrome, after the scene in Monty Python and the Holy Grail in which the knights decide not to go to Camelot after all, because it's "only a model." Scrum is only a model, too. Use it if it helps you, but don't let /it/ use /you/.

Enterprise adoption challenges for Agile by Rajesh Raheja

I agree that in reality there are times when you need to estimate the entire project; planning for a few iterations is just not practical for large scale productized project. I have covered some of the enterprise adoption challenges in my post: rraheja.wordpress.com/2010/11/23/3-reasons-agil...