Understanding Estimation for the Misinformed

When I speak with business professionals, they often struggle to understand the basics of the agile reformation.  For example, when I hold someone accountable for not doing work, they are shocked I am expecting results.  Many times, I feel like am discussing a round planet with people who still think the earth is flat.  These kinds of misunderstandings often lead to dramatic blow-ups as the agile coach expects one result and the business a different outcome.  This week and over the next few weeks I will try to explain some of the basic ideas agile practitioners use.  Today, an overview of why the agilest use story points.

One of the most controversial activities in business is project estimation.  The reason why is many estimates for creative projects is a lie.  The company is lying to itself about what it wants and how much it is willing to pay for it.  The creative team usually lies about how long it is going to take to complete the work.  To any objective person outside this process, it looks like madness.  Everyone is lying, money is getting spent, and nothing gets into production. 

Project Estimation is farce and tragedy.

The agile manifesto came into being with the twelve principles of agile because the failure of major projects in the business world was becoming unsustainable. The firm spends too much money for too little return on investment; something had to change.  The first thing the agile reformation addressed was estimation. 

A traditional project begins with executives looking at the corporate budget.  After the debt is serviced, shareholders compensated, and payroll met a portion of the money is left over.  Managers then submit requests to spend this leftover money on capital improvements and technology projects.  Based on profitability and political clout, this money is doled out.  For the attentive, you will notice the business executives do not experience the same reality of the front line consumers or employees.  Thus, a software project begins with a pile of money.

The managers and directors once they receive this money then have to figure out how to spend it.  The money comes with plenty of strings.  The project has to meet a deadline which may or may not be grounded in reality.  The plan must work with current technology at the firm.  Finally, the manager must have people who understand how to take that pile of money and turn it into working software. 

What happens next is something resembling a demented game of “Name that Tune.”  The manager goes to consulting companies and internal development teams asking how much time it will take them to satisfy the project requirements. The consulting company will bid a price to earn the business.  The internal developers will offer an amount to remain employed.  It goes on until the bidding ends and the project begins.  The costs are not grounded in reality, and neither are the estimates.

What happens next is both farce and tragedy.  The workers with the limited budget and impossible timeline fail to deliver.  Making matters worse developers are expected to incorporate changes mid-stream and the deadline does not change.  Eventually, the deadlines are missed.  The budget is used up, and cost overruns are rampant.  Finally, people quit because they are burnt out for working numerous hours of overtime to deliver a flawed product.  Quality suffers, money is wasted, and this approach ruins reputations. 

The primary cause for this kind of disaster is many managers equate time with money.  So, if you have $40,000 and it takes 1,000 hours to do something, this means it will cost $400 an hour.  Now suppose you have a consultant who will do the work for $200 an hour.  You can do twice as much work.  It depends on both of the people having the same skills and ability which is not the case. 

Story points for estimates came into being because time does not equal money for complicated projects.  Those projects also feature tremendous uncertainty and are often resistant to automation.  Instead of telling a manager that the team will be able to do the work in 1,000 hours at $400 an hour, a scrum master or product owner will say the team can do fifty story points a sprint and there are roughly 213 story points of work.  The ridiculous game of name that tune goes away and people can start having realistic discussions of time and money. 

Next week I will show you how that works.

Until next time.