Scrum Project Estimation Beyond the Near-Term?

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.

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.

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.

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.

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/.

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...