The diagram represents the Cone of Uncertainty—coined by Steve McConnell of Construx. I’m sure he’s not the first or only one to reference the cone, but he famously has connected it with software development. The cone indicates the futility of estimating & committing to software projects at project initiation—not matter how well conceived the estimates are. There’s typically too much uncertainty to be accurate. Instead, an iterative or incremental approach will glean more information to improve the estimates over time. This is particularly true for projects that include new technologies, new teams, or trying to create novel or innovative products.
I’ve been managing software projects for much of my career. Early on, I spent most of my time trying to estimate projects more and more effectively. I pulled together models for how to estimate. I kept track of historical estimate vs. actual data, so that I could evaluate the quality of my estimates. I even tried some modeling or arithmetic techniques to fine tune my estimates. Some of these are quite well know techniques like Function Points or Cocomo or the Personal Software Process.
All of this was focused towards estimate quality…not software product quality. I was worrying about how to represent the time to build the software to stakeholders and accountants so that we could reasonably know how much it would cost. Then we could make better decisions around whether to start it or not.
The odd thing, at least in my experience was that no matter neither how hard we tried nor how much effort we expended on estimation and planning, over 60% of our projects went awry. They failed. They were Death Marches. They were incredibly painful. And in many cases, they resulted in people losing their jobs.
I guess my point is—accurate software project estimation is incredibly hard.
Now you may say, well Bob, you simply were poor at estimation and didn’t really perform it all that well. My counter is that I am really good at estimation. I’ve studied a wide variety of techniques and applied them diligently. I’ve even taught software estimation at international conferences. So, while I still have much to learn, I’m not a tool-less novice.
And I guess my other more crucial point is—I’ve come to the conclusion that estimation was the wrong place to be focusing my efforts!
What the Agile Methods Have Taught Me
The first thing I’ve discovered is that estimates don’t really matter all that much. You don’t deliver estimates. Customers don’t use estimates to solve their problems. Estimates don’t have value. Working software that is delivered…has value.
So my primary focus has moved from estimating & planning towards execution & delivery. Does that mean I don’t plan? Of course not!
But if I have 8 hours of software development to complete, I only focus on planning for minutes. The remainder of the time is spent on fine-tuning my execution and delivery. On ensuring the software works. On ensuring it meets the customer needs and solves their problems. That’s where +90% of my focus is. On that and incrementally improving my execution…so every hour I might reflect on how well I’m doing and how can I improve my execution towards the costumer’s goals?
The Two “Levels of Agile Planning
When I first was introduced to the agile methods I was struck with the practicality of the planning. The methods broke things down into two levels—high level release forecasting and low level detailed iterative planning. More importantly, it was the interplay between these two levels over time that refined your estimates.
No longer did you try to predict a guaranteed endpoint for a project. Instead you gave a reasonable, high level view that you promised to refine every time you got real-time performance results from your team, i.e. completed each iteration. You would then narrow your view over time as you iteratively gained traction delivering real, working software. At each point of actual data, you would update your release plan / model and re-communicate to stakeholders where things actually stood in relation to their expectations and your previous views.
If you were behind schedule, stakeholders had the option of dropping, reducing, or re-framing scope based on business value and priority. But in order to hold to a date, they would have to adjust something.
If you were ahead of schedule, a not so rare event, they could pull in more value-based scope and deliver more than anticipated. Many traditional planners focus on the behind-state within agile teams. In my personal experience, about 80% of the time well-behaved and mature agile teams pull in more work than they originally planned. Very cool!
High Level – Release Planning
The methods don’t spend a lot of time estimating in excruciating detail at the high level. Instead you estimate work (usually expressed as User Stories) in generic level of effort / complexity units (usually expressed as Story Points) so that you can plan the number of stories you can fit into a series of sprints to meet a content commitment for your stakeholder.
Remember, release planning isn’t a firm commitment. Nor is it exhaustive, detailed planning. It’s a best guess, high level view to packing work into iteration sized time-boxes. However, there’s a missing point to accurately planning a release. What you might ask?
It’s the teams’ own velocity. Put another way, the teams’ ability to execute and deliver fully done stories within their iteration time-box. The first time your team actually delivers work from a 2-week sprint you have a wonderful data point—actual team velocity! Please don’t undervalue it.
Low Level – Sprint Planning
But I got a bit ahead of myself.
In the agile methods, where does the team dig into the details? Refining tasks, looking at dependencies, breaking things down into smaller, quantified (hourly) units of real work to be completed?
They do that on an iteration (Sprint) by iteration basis—grabbing a small “chunk” of the work, always the highest priority and most urgent work, and breaking it down for the very next Sprint.
If you ever get the chance to attend a proper Sprint Planning session, you’ll have transparent access into a software team breaking down work into very small tasks. You’ll begin to understand all of the complexity and nuance for each story. You’ll hear the testers challenging the developers on testability and how challenging this piece of code will be to test—which will add more tasks for testing and quality.
If the team feels a more detailed design is required, you’ll hear them discuss it. How much? Who should be a part of it? And what does the review look like? Etc.
In general, you’ll experience all of the complex gory details of software development—the real work involved for a single sprint. Then they’ll do something wonderful. They’ll commit to the work and deliver what they can (fully done) at the end of the sprint. You’ll now have an actual data point for the teams’ capacity that you can compare and contrast against the overall release plan—with full transparency into the plans and details and with no extra padding allowed.
How cool is that?
The above two models capture the choice to be made within traditional vs. agile projects. I’ve “borrowed” them from Mike Griffiths’ 2006 blog post. Surprisingly, many teams still struggle with how to approach estimation & planning.
I do quite a bit of sharing on agile methods nowadays—via presentations, formal training, and coaching. Believe it or not, I often get challenged on some critical aspects or techniques surrounding agile. None more than the point being made here.
The challenge goes – “There’s no way my boss will put up with a non-committed date for a project” or a “We’ll know how long it will take when we see it” approach to project estimation will not work in my company because we live in the “real world”.
My counter then is usually the same—“Fine, do what you’ve always done”. Try to predict the future on a highly complex software project without doing any real development. If you can guess correctly, then great—stick with your practices.
BUT, if you notice that you often fail. And by often I mean 50%, 60%, 70% or even 80% of the time to successfully meet your stakeholders expectations, THEN your practices are clearly not working for you.
Admit that and try something a bit different. Agile Project Managers make the above approach work every day in a wide variety of business, customer, and technology contexts. It’s no longer a bleeding edge technique! It simply drives more real-time transparency into project progress. It helps with adjustment based decision-making. And it leads to more collaborative and successful outcomes.
From my perspective, if your methods aren’t working that well for you then what do you have to lose? So, what DO you have to lose?
Thanks for listening,