Skip to content

Agile Estimation – 5 Ways Estimates w/out Priority Fail

Agile Estimation - Ways it Fails Without Priority
Agile estimation requires an understanding of priority in order to have accurate and successful estimates. Practice good Agile Estimation techniques to help consistently deliver value.

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.

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

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

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.

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.

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.