My most recent article on projectmanagement.com is 3 Questions to Ask Before Estimating an Agile Program.
In both Create Your Successful Agile Project and Agile and Lean Program Management, I talk about the reality of estimates in most settings. The question is what kind of an estimate does your project or program need?
I'm not opposed to estimation. I need to provide estimates to my clients and myself. And, I find that to provide order-of-magnitude estimates for projects and programs, I need to ask some questions first.
Here's an example of why you might want to ask these questions. Imagine you are driving to two different places. One is within a half-mile of your origin. The other is across town, with traffic, several miles from your origin. If you could see value with the close destination and then not have to drive to the other destination, that would change your estimate. You also need to know the time of day to estimate the effects of traffic. And, that your driving time might change depending on the state of the roads.
We have similar problems at the start of agile projects and programs. At the beginning when the execs want an estimate, we have these problems:
- The feature sets are too undefined to estimate with enough accuracy. (Do we have the exact street addresses, or do we need to refine the address once we start?)
- We don't know how we might change the order of the features in the feature set or the order of the feature sets themselves. The order of the work might matter. (In my driving example, which location you drive to first matters.)
- We don't have the teams yet who will work on these features. Or, the teams don't know the state of the code and tests. (Is someone familiar with the main roads and back streets driving, or is it someone unfamiliar?)
We might have more unknowns.
That's why I like asking the questions in 3 Questions to Ask Before Estimating an Agile Program. I have found the questions prompt great discussions. The discussions help me frame risks I might need to manage as we proceed.
Enjoy!
The approach used in our software intensive system of systems domain, where requirements emerge, needed capabilities change with external events, is to start with understanding the needed Accuracy and Precision of ANY estimate. Document that needed accuracy and precision in the “basis of estimate” agreement between the provider (us) and the consumer (customer).
Only then can a credible estimate be started.
So when those “executives” ask for estimates, we first need to answer
▪︎ “The feature sets are too undefined to estimate with enough accuracy” – What accuracy is needed to meet you needs. As well what precision is needed to meet your needs to make a decision in the presence of uncertanty.
▪︎ “We don’t know how we might change the order of the features in the feature set or the order of the feature sets themselves” – what are the “possible” changes? What’s the probability that any one of those changes will impact the estimate? What’s the coupling between all those possible changes from an architecture or development point of view? Meaning, are some changes undesirable at this point in the project? Ae some changing irrelativent? This is a systems design process.
▪︎ We don’t have the teams yet who will work on these features. Or, the teams don’t know the state of the code and tests. – if you don’t have teams, what has been the historical performance of past teams in the firm? This is a “Reference Class Forecasting” model. What has been the statistical processes for those team’s performance. “The Flaw of Averages” is always in effect. Simple AIRMA (Autoregressive Integrated Moving Average) models in Excel or R will show you the dynamics of the future if you have data from the past. If you don’t know the state of the code, tools are available for that. Visual Studio as some, other tools like LATIX provide assessments of the “integrity” and many other aspects of any common code base. This is also part of Reference Class Forecasting and Basis of Estimate where we work on Enterprise IT, embedded systems, process control and other system of systems.
The question of “Value at Risk” will provide the incentives to investigate methods for answering those questions. Low risk – no one cares. High risk (and high value) estimating is a critical success factor.
Here’s one place to start https://www.amazon.com/Estimating-Software-Intensive-Systems-Processes-Engineering/dp/0321904923
But again, depends on your Value at Risk
Glen, thank you.