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.

Summary

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.