Why do I use #NoEstimates? Certainly the first reason is obvious in the name of this movement. But there are may other reasons. One of the reasons that does not get enough airtime is that it creates more options than using pre-estimated methods to manage software projects.
Value is unpredictable, generate options to explore the value space
When we estimate a software project we make certain assumptions about what work and how that work will be completed. We need to do that in order to sequence the work, handle the dependencies, assign the work to the right people, etc. Estimation is a process of planning, and as such it requires us to make commitments. Those commitments reduce our options, because we immediately eliminate possible implementation strategies.
Let’s look at an example. I want to implement a IT-request queue in my organization. Something that allows us to manage the requests from employees in a way that none is lost and the employee can easily get information on how the item is proceeding through it’s life-cycle. A project is started. How to plan this project?
- The Estimated approach: In this approach I get the team together we list all the work that needs to be completed (database changes, UI for form input, queries and IT ticket management, server deployment, testing, etc.). We schedule this work according to skills and availability of people and end up with a schedule. This schedule will be implemented by different people. Because of this, I will have to follow-up with each person, to make sure we have each necessary task completed before the work on the next tasks begins. This is how we would typically handle the dependencies between these tasks.
- The #NoEstimates approach: In this approach I ask the team: “What is the most important work that we need to complete NOW?”. Tracy says: “The IT ticket handling is the most important part. We can add the customer-side UI later and handle incoming requests by email until then”. Bingo! I get the list of tasks for that specific functionality from the team, and it looks much smaller: Database changes + IT UI development. The immediate benefit is that the dependencies are fewer (and we will make them even fewer with User Story splitting), which means less coordination, and valuable functionality delivered earlier. But the key point is this: We have more options! We have made the necessary commitment to deliver something of value, but not made a commitment to the planning for the whole project.
One of the key benefits of using #NoEstimates as a planning approach is that we create more Options, making our projects more valuable and more flexible.
In the #NoEstimates approach we release a partial set of functionality (value) earlier. We may find that for the time being that functionality is enough and may decide not to release any further functionality (an option). Or we may find something we did not know before, and change the project (another option). While in the Estimated approach we will make commitments in terms of time, people and resource allocation that are going to be harder to change later (reducing options), and may commit more money to the problem than we actually need (less options still).
With the #NoEstimates approach we don’t commit to requirements that we are not going to immediately work on
Note also that with the #NoEstimates approach we don’t commit to requirements that we are not going to immediately work on. The reason is simple: requirements have a “best before” date and expire. We should not commit to requirements too far into the future – but that we will tackle in another post.
Have you applied this planning heuristic in your projects? What were the benefits, and obstacles you faced when using it?
Photo credit: psiaki @ flickr
3 thoughts on “Use #NoEstimates to create options and deliver value reliably”
So in that nice picture of the X-wing and the list of needed “features” in the example, where do those parts get designed and the list get developed.
It seems obvious hat once you get the list of work to do no estimating is needed once you have determined the work effort needed to “assemble” the pieces. That’s straight forward – or as straight forward as could be expected given the technology. The “some assembly required” carton for any christmas gift for example.
But it seems to me – at least in the domains we work – that the difficulty with estimating is the discovery of what to do. How long will it take to develop, test, verify, and fly the first article of the Guidance system for our UAV for example?
The “No estimates” paradigm you are describing is logical. Wondering how much of the SWDev domain fits into those types of “predefined” assembly type projects? Most of the development programs we work do not.
So we’re back to the universal question, where does this work?
Nice article, Vasco. But what you’ve just presented as a #NoEstimates approach seems to me much like an Agile approach. I couldn’t see much value in the #NoEstimates itself in this scenario.
Most ‘agile’ approaches will still use estimates even if they don’t call them such. Your velocity and the points given to a task are all estimates.
There are too many unknowns in development to be able to make accurate predictions. We see this every day with budget and time overruns – you just can’t gauge too far in advance and expect it to be accurate without having done something identical before.
The emphasis, as Vasco points out, should be on concentrating on delivering value to the client.
Comments are closed.