Estimation is one of the pillars of agile development. On a personal note, it’s the main reason that I fell in love with Agile as a way of managing projects. I have, in previous presentations used a practical example to explain this.

I was sitting at my desk a few years ago working on a Gantt chart. I love Gantt charts! Their ability to illustrate required and related activities over a timeline can’t be matched. What dawned on me this day though, was that too much detail on a Gantt representing a software project, can have you lying to yourself about what you think you know!

I was mapping out a six-month software development program for a handful of developers.

I had done all the prep work. Discussed every aspect of the requirements with relevant stakeholders and the developers themselves. I had mapped out expected durations for the development of each feature, and I was now translating this to a sequential series of events neatly illustrated on my Gantt.

The project started in July, and as I documented the activities of September it hit me. “Wait a minute, do I really know what Marcus will be doing on September 6, between 1 PM and 5 PM?” Of course I didn’t. A lot was going to change between now and then. We’d learn a lot as we went, and my Gantt would need to change. It suddenly seemed preposterous to me. The arrogance and futility of trying to produce a document that I knew was immediately inaccurate, struck me as such a waste of time, that I questioned the value of writing this stuff down at all.

It all comes down to the fact that we can’t accurately predict how long any one aspect of software development will take. Traditional project management is suited well to industries like construction, where the duration of activities can better be estimated. With experience, such things as the number of bricks one person can lay in a day become common industry knowledge. As does the cost per brick. A linear improvement in progress can be seen when more bricklayers are added too.

Note: I apologise for this oversimplification. Construction planners face complexity that I’m sure I do not understand. I only hope to point out that many activities in such projects are more “known”, or better understood prior to commencement, and therefore more accurately estimable for duration.

Software development is very different. We ask developers to use their technical capabilities in creative problem solving, answering questions that have previously never been answered. We asked them to do so efficiently and innovatively, providing product users with a satisfying experience through architectural elegance and well considered (but brand new) UX. We then asked on (or worse, tell them!) How long this will take.

For some time I have fostered in my teams and understanding of relative complexity sizing. The wonderful work of Mike Cohn in his book “Agile Estimating and Planning” describes the use of story points as the basis of comparison between units of work.

I love relative sizing, because it (theoretically) does away with attempts to inaccurately assign a fixed unit of time to the delivery of software feature (“this is a four hour feature”, “that is a three day feature”). By comparing relative complexity of a proposed user story, to those that have been done before, Cohn believes it possible to simplify and speed estimation, for the purposes of planning and measuring progress. The estimates are not precise. Sometimes they are inaccurate. The point is, this will be true of any estimate we try to impose upon the effort of software development prior to commencement. We just don’t know. Regardless of how we come up with our estimate, it’s a guess, and it feels GREAT to admit it.

So the goal becomes to get as good an estimate as possible (we need this for project planning), in the shortest amount of time, so that the process of estimating is not a burden.

See Part 2, for my take on the best way to get about this