In your organization, are estimates and time frames asked for before priority is known? Do you get the feeling that this leads to a disjointed process and doesn’t enable teams to go do their work? But, it is so common that you don’t question it. Just going along for the ride. Well, this is not Agile estimation.
I see this approach to work all the time. Organizations want to know the estimates, scope, time frame, and by all of this, the cost, of the work first. This is understandable. We always want to know what it is we are getting before we buy it. However, in software and product development, you don’t know these things until you start on the work. You may have some best guesses, but they will likely be wrong or change along the way.
Check out the following reasons Agile estimation doesn’t mean you get estimates before you know a priority for the work.
Agile estimation helps get value sooner
Some teams work out a process to do some kind of estimation up front. That can be done, but all that does is take teams away from the completing work. By this I mean that teams can either work on completing software and product development work. Or, they can work to understand future work, or work that is not underway. By doing the 2nd, you slow down the first.
When asking for estimates on work before a clear priority is known. You are circumventing the priority order. Thus impacting delivery of the top priority items.
If priority includes value, which it should and must, then you are delaying the achievement of value for your organization by circumventing the work by priority order.
- Requiring estimates before you even have a priority for the work delays the value gain.
Agile estimation is estimation from the team
True estimates come from the team doing the work. You can’t have others not involved in the work or someone that isn’t going to do the work doing the estimates. Estimates are relative and change from person to person. And change from team to team. This requires that Agile estimation be done by the Agile team doing the work
2. Estimates from other than the team are likely wrong.
There is a natural cadence to doing estimates. as part of the normal team rhythms. By this I mean they will estimate work as they start to get the next queued up work ready. pushing for estimates outside of this normal cadence only disrupts the flow of the team
You also won’t have good time frames for delivery without understanding priority. because of all the other work items that are going on. You have to understand relative priority amongst the varying work, to truly grasp when a given piece of work might be able to be completed
3. Estimates disrupt the processes of the team.
Agile estimation is not about estimation
Agile estimation is more a planning tool for the team and to help them organize around the work to be done. It is not about planning out exact levels and timing of work.
4. Requiring exact estimates only leads to failure.
Agile estimation requires flexibility
In software and product development, the work is constantly in flux. Needs and goals will shift. New work items come up that cause a shift in priority. This is a given, yet it still goes unrecognized in the estimation of work. All too often, teams try to stick to estimates of work that has completely changed on them.
That is a failure by the organization to not be responsive to change and embrace it to really work towards top priority goals and value.
5. Agile estimates will change, thus estimates will change. Because the work is continually changing.
Additional content and reading that helps with Agile estimation
A great piece of information on Vertical Slicing is available here. Which helps to break up work and work things according to priority. Or another great read on Agile Estimation ideas can be found here.