Is Estimating A Waste Of Time

Is Estimating A Waste Of Time?

Our world is built up of plans and estimate, business judge the CEO’s and senior manager by the estimates they produce and how they deliver on them. Without estimate we can’t prepare for the future.  In our daily life we plan using estimates, like how long will it take us to get to the airport, how much will we need to put aside for our summer holidays (vacations?)

The process of doing estimates has significant influences on our decisions making. For example can we afford our trip to France, or how long do we leave for the airport before the flight. Failure to make accurate estimates could have a lasting impact. We could miss the flight, or we could overspend on the holiday resulting credit problems.

Clearly for big business and for smaller personal decision estimation is vital. It is no less vital for our development or business change project to have a handle on the costs and delivery timescales. But is estimation the way to do.Business stakeholder need to incorporate the estimates into their cost and deliverables. They need to be bought into the estimate in order to buy into the project. When an estimate is asked for, it’s critical to understand why an estimate is needed.

In scrum we estimate in detail, scrutinise, reviewed and update these estimates regularity. But the purpose and timings of these estimates is not what the business stakeholders is looking for.
Business stakeholders want to have some idea of when they’ll get which features, the number of resources needed to meet a timeline, and of course costs. None of this information can be provided without taking time to do some estimation and planning.

To get to a satisfactory solution to the conflicting requirements we need to separate out the stakeholders requirements into the 3 elements and deal with them separately.

1. Planning
Planning gives the business an idea of the resources timescales and activities. The act of planning is a large part of the value, not the piece of paper the plan is written on. This plan is not about specific component delivery but about how we deliver the cycles and more importantly it is to come to a shared understanding of what we as a team can achieve.

2. Budget
Budgeting projects uses a top down approach, where you decompose only so far as you need to in order to have enough information to make your decision.
Budgeting can be done in much less time and Budgets make better sense “what can you do for €XX.xx” This approach clears the way for the product owner to set some of the priorities.
Secondly Knowing the customer’s or management budget expectation impacted the developers’ estimates. It’s called anchoring.

3. Agile Estimates
It is easier to have confidence that we can accomplish small things than big things regardless of what number we attach to that smallness/bigness. Agile estimates are small, lower level and feed into the budget and cycles that we have set out.
We are close to the action and have more confidence that we can deliver the controlled delivery. Smaller results in less variations and the variation in estimates easily to manage. The delivery teams can then stand over their estimates.

Agilists must accept the need for revenue and budget forecasts to be taken seriously

It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects.
Breaking it into the 3 process can satisfy bot the business and the agilest.