How to Enable Estimate-Free Development

Most of us have been there... the release or sprint planning meeting to goes on and on and on and on. There is constant discussion over what a story means and endless debate over whether it's 3, 5 or 8 points. You're eventually bludgeoned into agreement, or simply too numb to disagree. Any way you look at it, you'll never get those 2, 4 or even 6 hours back - they're gone forever! And to what end? Some of the Stories could have been completed in the amount of time it took to estimate them, while others drag on for days and even weeks longer than anticipated due to different interpretations of what the story meant.

It doesn't have to be like that!

In "How Thin is Thin?" An Example of Effectively Slicing Stories, I wrote about techniques that can be used to slice Stories to be extremely thin while still providing value. Near the end of that post I listed a number of benefits you receive by using these thin slices, including one very important factor that the practice enables - elimination of the need to estimate Stories. I wrote,
With Stories sliced as thinly as possible, they all become nearly the same size in terms of effort. Therefore, no estimation of individual Stories is required and a team's capacity can simply be derived by counting the number of Stories completed for some unit of time.
If you haven't already read that post, I suggest you do so now because it will provide some context for this one. Don't worry, I'll wait for you!

While there is still the need to write and split Stories, that activity is much less arduous since the only question becomes, "Can we split this any further and still deliver value?" Note that you still need to define acceptance criteria for a Story, regardless of how thin it is. Often you can identify Stories that require further splitting when those acceptance criteria become complex or simply grow to more than a few specific items.

When Stories are that thin, the need for breaking them into tasks also becomes questionable. My experience is that you sometimes will need some tasks, but most often you don't. That removes yet another activity that eats time and often the souls of the people involved!

But We Still Need To Estimate The Project!

In many cases, you can't even start work without some form of approval, which often entails a high-level estimate of the overall cost. This project and budget approach has numerous issues, but I'll save them for a later post. For now, let's assume that you need at least a high-level estimate of the cost in order to feed the accounting and portfolio management machine in your organization. How can you possibly do that without estimates of the Stories? How can you provide an estimate the first time you're using a no estimates approach?

First of all, the process of breaking all the work down, estimating each individual piece and then adding up all the estimates is fraught with issues:
  • "Who" performs the estimation will affect the value, and most teams I've observed will only involve senior people to estimate work before a project has started;
  • Everyone adds their own "fudge factor" to the estimate at each level - a developer will add time, then that person's manager will add a bit, the PM will add a bit, etc. until the estimate become less and less meaningful;
  • To have any chance of being remotely close to a realistic estimate, you will need to break down all of the work, which is a relatively long process for what it provides - a SWAG.
The best approach to dealing with this that I've encountered is Story Mapping, created by Jeff Patton. In a relatively short period of time you can collaboratively create an overall picture of the work to be done, and actually "see" how large a system will be. Armed with a Story Map, a group can then use a couple of different approaches to creating that high-level estimate.

First, you can ask for a small budget to create some thinly-sliced Stories from the Story Map, and then actually start building them. After all, there's no substitute for real data! Slice the Stories as thin as possible, start building the most important ones and count the cards completed over some interval. For this "discovery" stage, that might be a week. So, the budget could be for perhaps one month of a team's time. Determine what the team costs for that length of time and you have your budget.

At the end of that month you should have 3 or 4 actual data points for the number of cards that can be completed per week. You can also look at how much was completed of the higher-level Story Map to get a rough idea of how much more there is to completed before enough value has accrued to deliver something to the people who will consume the software. That "rough idea" is now an overall estimate for getting a first cut to production that's based on real data points and much less conjecture. Oh, and by the way, you've already delivered real value during this discovery step!

If you're in an environment that wouldn't allow this discovery-based approach, there's another method that I mentioned in "How Thin is Thin?" It's called Blink Estimation, and was described by Dan North. The fundamental premise of Blink Estimation is that once you have experience building systems then you are actually pretty good at making macro-level estimates. Dan's assertion fits my own experience well.

Back in the 90's, a manager of mine back asked me to look at a system quickly (I think I had 5 minutes) and tell him how long I think it took to build. I was able to see the general areas of functionality, play with it a bit and came up with an answer of 40 days. He laughed out loud and told me I was wrong... it had taken 42 days! I'm not some wunderkind of estimation, but I knew the technology used and was able to reasonably gauge the complexity and the rough "size" of the system.

I wrote about that manager in Agile Circa 1988, in which I described how the team with whom I worked had built a large-ish HR system using relative estimation without having to dig too deeply into the details of each module they were building. The people involved leveraged their previous experience in that technology and that business domain and provided an estimate. The people in management were mature enough to know and estimate was just that - an estimate - but the team's track record consistently showed that those estimates were good enough to use for planning and budgeting.

We Have Approval, Now What?

I learned the concept of simply slicing and counting from Ron Jeffries, who has been advocating since 2004 that Running Tested Features are the only truly valuable metric in software development. These thin stories with well-defined acceptance criteria are those running tested features.

You aren't just checking off tasks, you aren't calculating earned value, you aren't staring at a Gantt chart trying to figure out where the project should be, you're creating features that are ready to be used as soon as they're completed. That provides everyone involved - the team, stakeholders, customers - a much more accurate view of your progress towards delivering the work. It enables the people steering the work to deliver partial functionality early, if they prefer. It gives the team a constant sense of accomplishment because they know that when some work is done, it's really done because it has been tested to meet the acceptance criteria established, and ideally has had exploratory testing performed on it as well.

In other words, real progress is visible to anyone who wants to see it.

If you're focusing on the stories that provide the most business value or mitigate the highest risks, that progress allows the people for whom the system is being built to make well-informed decisions. For example, they may choose to ship a simplified version of a system earlier in order to obtain real-world feedback or to establish an early position in a emerging market. An early version that actually works and can be used by real people is also a wonderful way to obtain further funding to complete a system!

Lean In

In Lean terms, thinly sliced stories flow through a team better than larger ones. This concept is similar to difference between pouring sand and pouring gravel through a funnel. Because the particle size is so small with sand, it flows freely.

Gravel, however, has particles that are larger and vary greatly in size. As a result they can become lodged together and block the flow completely without intervention.

Any delivery process seeks to maximize the throughput of work, and making the flow of that work as smooth as possible will achieve that. Two key elements of maximizing flow are to minimize batch size and to minimize the variability of the work items. Slicing stories as thin as possible achieves both of these goals. Gone are the days where a story is estimated at 13 points using the popular modified Fibonacci series technique, and it takes multiple iterations or sprints to complete! Also gone is the wildly varying difference between that 13 point story and a 5 point story.

As mentioned earlier, gone as well is the need to even estimate the stories in the first place! Just keep slicing until the story is almost transparently thin. In How Thin is Thin?, I used the example of graphene, a 1-atom thick sheet of carbon that's 100 times stronger than the equivalent amount of steel. Just like graphene, very thin stories are disproportionately strong and enable teams to work much more effectively.


Teams are always looking for ways to decrease the time it takes to deliver software. As I've presented here, thin stories will enable you to eliminate the need for low-level estimates for those stories. If you're in the position of having to provide high-level estimate, I've also shown two approaches to estimating at the macro level for these larger amounts of work.

Working with these thin stories allows you to work more predictably and avoid the bloat encountered with larger stories that more mainstream estimation approaches allow. You also avoid the debates over whether a story is 5 points or 8, and a team's capacity is calculated simply by counting the number of stories completed over some period of time. This means that the time invested in planning exercises is actually spent on planning by focusing on what needs to be done and not the effort required to do it.

I'm not asking you to take a leap of faith with this approach - it's being used in the good ol' real world as you read this. You may need to adjust your view of what "thin" means and similarly your view of what represents value to the business, but those are very simple barriers to cross. I can even help if you like.


Ted M. Young said…
I'm sure this doesn't need to be said, but if the architecture/codebase doesn't support implementing thinly-sliced stories that provide value, you're gonna be pushing gravel and rocks through the funnel, which means you're gonna need estimates. You're also assuming that "done" = "delivered", which is not the case in an environment where code doesn't get shipped to users for months, if not years.

This means that if "management" wants better estimates and better "flow", they need to support an architecture that will allow for smaller stories-that-provide-value. Alas, "management" is typically aligned with (or made up of) sales, which is always about features over engineering.

Also, the "experts estimate, managers roll-up" is somewhat of a straw-man argument: many teams estimate as a team and there's no rolling up, though there is a "fudge" factor added at a higher level.
Brian Button said…
This is a great post, Dave. I plan on showing this to a lot of people :)

The big thing that stokes the controversy about this approach versus the estimates up front approach that others favor is context. There are contexts where that BigEstimatesUpFront approach is necessary and critical, I believe. I also believe that those projects are generally big and complex already, and have more formal governance challenges.

For the right context, this solution is every elegant and works remarkably well.

Again, great article!

Dave Rooney said…
@Ted, when I did work in telecom, I was told that it was impossible to implement a simple happy case scenario within even a 3 week iteration. I believe it was Craig Larman who suggested that the exception scenarios be done first, which would then start to build the necessary infrastructure and processing to handle the happy case.

Also, if you read my previous post, "How Thin is Thin", you'll notice that the first story was almost entirely hardcoded. Of course that story isn't going to be delivered to production that way! It did, however, build out the basic infrastructure required to create an Order and save it into the DB. That's a running tested feature, but by itself it doesn't have enough business value to warrant shipping to production.

As for estimation, I've seen both approaches. The more prevalent one has been senior developers estimating in the absence of any QA and much business input. That has almost universally resulted in optimistic estimates.

I *have* seen and been part of collaborative estimation at the high-level, and have seen it work well.
Dave Rooney said…
@Brian, thanks for the comments! I did mention that the approach I favour is to do a Story Mapping exercise to understand how 'big' a system is going to be. The macro-level estimate created with that input is going to be just as good as one created from breaking every little piece of a system down. Yes, it's still up-front decomposition and estimation, but that's OK!

The business domain of the software will help define how much up-front work is necessary. Life and business criticality factor into it, as do regulatory requirements.

Regardless of how much up-front effort is required, I still advocate slicing stories as thin as possible and just counting them rather than estimating each story.
Gekko said…
Liked this post a lot and it gave me a lot to think about. As a tester I like the approach especially because with thinly-sliced stories we get to "know" what the system does and how it slowly evolves into this massive beast full of things to test.
So instead of head over heels to estimating and testing a giant beast we know that we will get proper introduction to the system and its features. This in turn allows us to have better information on the quality of the system.
Thanks for this article!
Glen Alleman said…
Nice post, the notion of "as thin as possible" is closely related to Reference Class Forecasting in our Defense and Space domain.

The effort the decompose the slices is the cost of producing a credible estimate for whatever cycle you are applying it to. We only detail plan for the current rolling wave. Future waves have "planning packages." Current waves have Work Packages (1 iteration with Tasks not baselined but managed by the team in V1).

The whole No Estimates notion is misdirected and you've put it back on track with this approach.
Technically this approach would be accepted as the "basis of estimate" for the contractual obligation to establish a cost baseline in DOD/NASA procurement using Agile.

One ½ time client is a policy maker in DOD working on guidance for Agile in the presence of Earned Value. Lot's of work done - Google "DOD Agile" to see reports. But the estimating and performance assessment - 0%/100% is the prefered assessment - can not be "informed" by this approach.

Our you or have you published this idea formally - conference or journal - so it can be referenced in our study contract?
Unknown said…
Great post, I thoroughly enjoyed reading this. It appears we have a broken link for "how thin is thin?" Both references are leading to page not found.

Unknown said…
Great post, I thoroughly enjoyed reading this and hope to use some of these in our environment.

We appear to have broken links to "how thin is thin?" Getting page not found for both references.