Stories and points of Agile Project estimates

Introduction

When you hire a painter to decorate your house, or a repairman to fix your car, you ask them to give an estimate first, right? You need to know how much it will cost and how long it takes. This is common sense.

But what does experience tell us? How much difference does the initial estimate have to the final bill? It is quite possible that the paint trade union found loose plaster needed to be eradicated, and the walls needed to be repaired and repainted; the repairman will find that there are other problems to be solved in order to get your car back on the road. In the 1951 New Yorker magazine, there was a cartoon, Syd Hoff drew a repairman to his client and said:

"Of course, that's just an estimate, the actual cost will be more."

If the painter or the repairman told us that these problems are not very urgent, we can choose to temporarily do not deal with ... However, the usual scenario is that we feel compelled to fix those additional problems. Who would want to live in a house that might be damp in the wall, or in a car with a possible steering wheel failure?

So how do we solve such a problem? The common practice is that we insist that the worker give a comprehensive estimate of the final price, which is usually called the "quote", so that the worker will spend more time on more accurate estimates. However, in reality, no matter how hard they try, they still can't predict the unexpected problems.

In the project, we face the same problem

Traditionally, project managers are often committed to creating very detailed estimates that can withstand scrutiny from a financial standpoint. Of course, such estimates are based on predictable scenarios coupled with contingency budgets for "known unknowns" ... However, as Donald Rumsfeld's famous quote says, "There are some unknowns that we don't know about--there are some things we have no idea we don't know." Like the businessmen above, we can never predict those unexpected situations.

The longer we spend creating detailed estimates, the more trouble we have. We can think of a detailed estimate as a binding quote, a goal different from the true value of delivery, which allows us to focus on delivering something in terms of the date and cost of the agreement-anything, regardless of its value.

In the review review after each implementation, the gap between the initial estimate and the actual is always a shock to us, and then tell us to try harder next time. Einstein once said that insanity is "doing the same thing over and over again, but expecting a different result." So things should not be like this, there must be other better ways.

Is it obvious that agile projects are not? Why don't we start with a ballpark requirement and then sort out the details in the process? Well, yes, but it's not all right. In agile projects We do not create detailed estimates to constrain ourselves, but it is important to have an understanding of the size of the work to be done, and that is why ...