I reckon this is the perfect question to start a book on estimation with. There are quite a number of factors that influence the quality of estimates, all of them present in different shapes and shades at each effort. I don’t claim to be exhaustive, but there’s a quite a list of embarrassing reasons why software estimation is hard and sometimes impossible. These have to do with a small number of factors:
- Size and complexity. Either it is difficult to establish the total size or complexity of the project at hand.
- Velocity. Or it is unknown has fast the project team will be able to realize this complexity. The speed a project team is capable of handling the functionality with is often referred to as the velocity of the team. Most organizations or projects haven't got a clue to what the velocity of their teams is.
There is a straightforward way of learning more about both of these factors. Evaluate your projects on a regular basis. You should not only evaluate your project at the end of your project, because that is of no use to the project you're evaluating, but far more regular, say once per stage, or preferably per iteration. And with such evaluations, also referred to as retrospectives in some agile literature, you should always establish your iteration velocity. Find out how much functionality you've realized, and find out how much time the team spent on realizing that functionality.
Recipe for estimation
So here's a recipe for doing software estimation:
- Find a countable unit. Find a work item you can count in your project; be it classes, use cases, tables, forms, reports, data flows.
- Count finished work items. Count the number or items of this countable unit that have been finished, either in the last stage (or iteration) of during the whole project.
- Count time. Count the total amount of time spent on realizing your counted units.
- Calculate velocity. Now calculate the velocity for your project team, or even if you're into details, the developer velocity.
- Extrapolate. Extrapolate these figures towards the remainder of the work items to realize.
This doesn't sound too complex, does it? However, much to my surprise after all these years that this business exists, it this is complex to most people.
What is the size of your current project?
Let me give you a very clear example. In June 2007 I presented a seminar on estimation and planning with smart use cases in Amsterdam, the program being much like the content of this book. The room was packed with about 80 participants. Right at the start of the seminar I asked the audience a simple question, perhaps a question to ask yourself too.
What is the size of your current project?
I imagined this should not have been a too difficult question. To make answering this question even easier, I added that I didn't care how this size was expressed - in function point, use cases, domain object,s entities, lines of code, user stories or even empty pizza boxes. Nonetheless, I was very surprised by the answer from the audience. Only one single participant actually had an answer. 1 in 80. He's said in a hesitating voice: "I believe our project is about 600 function points in size." None of the other participants had a clue.
This was not a unique situation. In any of the previous edition of this seminar, I had a similar response. People just don't know. So why is this? Why don't people know the size of their project and the speed their traveling at? Let's investigate.
Countable units
===Count===
Velocity