Work effort estimation is hard, still we often have to estimate. Unless you are on an agile contract, clients want to know time and price in advance. Estimate is a guess not a fixed number, it’s probability distribution that says when a task is likely to be finished.
We use estimations to make commitments to our clients. They pay agreed price for a ultimately working products. They want cost to be fixed and they pay for the risk of our bad estimation which is contingency applied to tasks later included in price along with a margin.
If you have to estimate, doing it in quick and accurate manner is crucial to your competitiveness. Unfortunately quick and accurate contradict – you need time to change your assumptions into knowledge. In business confidence in estimation can be your big advantage.
Estimations should be accurate in 50% cases and with low variance. Some tasks will be finished before expected time some after that.
But how to estimate?
First and foremost remember estimation is a guess. The biggest single factor important for making good estimation is engaging several people in the process. Planning poker is an Agile implementation of this principle first described by James Grenning in 2002. Planing poker session starts with facilitator presenting a problem. After short discussion, everyone engaged presents group his alone chosen estimate. Big differences in estimates are good to advance discussion and maybe reach consensus. Any method you choose, one thing to remember is to engage several people possibly with disperse experience and knowledge.
Tasks should be imaginable, try dividing work into chunks that last at most 3 days. It forces you to think about what is really to be done. A good habit in long running organization is to collect data about historical project and tasks duration. Comparing tasks to similar from the past is a good practice and works in many organizations. If you have no fortune to access data like this you should always involve someone experienced in the estimation.
We (humans) are poor estimators. In IT it’s usually bad assumptions and optimism that lead us to wrong estimates. You can more or less mitigate bad assumptions problem confronting multiple opinions. Optimism can be transitioned to reality by a long work of realizing what is in fact being done in everyday work. How we did just this will be described later on.
By comparing tasks to one another you can verify your estimates and limiting number of allowed estimation values helps. Planning poker cards use Fibonacci numbers – 1, 2, 3, 5, 8, 13 … Idea is to make comparison easier by creating distinguishable groups of tasks. You should not spend time discussing whether logging into application takes 5 or 5.5 days, better spend it on making sure it is not 8.
There are tasks hard to estimate especially if needs are vague or environment unknown. E.g. integration with other system should be straightforward – it has been done before but a few years ago with another version of the system and for a client we knew for a long time. This time is not so obvious it will take 2 days. In case like this you can try PERT estimation technique. PERT was developed empirically, it uses 3 numbers to provide you with expected task duration, good thing – it makes you think about worst case scenario. To estimate using PERT you need 3 numbers:
- optimistic time (TO) – minimum possible time required to accomplish the task
- most likely time (TN) – most likely time for you or your team, you expect normal circumstances
- pessimistic time (TP) - highly pessimistic time – 1% of probability, everything goes wrong
Now expected time can be calculated TE=(TO+4*TN+TP)/6. In our integration case it might be TE=(1 + 4*2 + 8)/6= 5.6
User stories, epics, parts of a project
Usually when estimating new project we do not have enough time and information to be precise. Preparing detailed work breakdown structure is impossible. We have to stay on higher level and still deliver useful numbers.
What we can do is to estimate effort needed to complete parts of the project. Method that we use is based on mutual comparison. Having identified parts of a project we classify them using what seems to us their relative size. For a start you need a whiteboard and some postit notes, which you place on a horizontal axis with cards depicting smaller tasks on the left and bigger tasks on the right of the board. See below.
When comparing is finished you can divide your cards into classes e.g. S, M, L, XL. Names and number of classes does not matter much – keep it simple. Check several cards and make sure they fit the same class. Make classes distinguishable – card should fit one class only. After that you are ready to calculate numbers. Assign each effort class number of days you think developer (or a pair, or a team) will need to accomplish a task from this class. You need to guess this number experts’ knowledge at this stage.
Calculate everything and check if the number matches your gut feeling.
You can do this for existing agile project. Just assign effort classes number of story points and calculate time using your team’s data. For a new project or a team just use time.
Is everything estimated?
Finishing a task takes more than just programming. Programmers estimate from their what-is-real-work perspective, but there is a lot more. After many estimation sessions we realized that the prerequisite to calculate useful numbers is understanding what programmers really estimate. Ask this first to establish common ground. Understand clearly what is that your team does every day. We did this by ad-hoc instant messaging poll, jabber bot would ask randomly chosen developer simple question “what are you doing right now”?
- programming – 48 (50%)
- documentation - 3
- integration testing – 3
- meeting – 5
- talkign with the client – 2
- nothing, i’m blocked by others – 2
- nothing, hardware problems – 3
- learning – 9 (9.5%)
- other things – 20 (21%)
When estimating time needed for project organization remember it is not only PM time, it’s project organization and affects everyone working. In an agile team it can take as much as 20% of the time – PM work, planning, standup meetings, retrospectives.
If you are convinced about your estimation, you should be able tell your client, with clear conscience that it corresponds to your understanding of the problem. Do not haggle over the estimation numbers alone, talk about the assumptions that underlie disagreement. If your client expects lower price, don’t juggle estimates but give him a discount.
Clean Coder Robert C. Martin
Wikipedia contributors. “Wideband delphi.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 24 Jan. 2012. Web. 17 Sep. 2012.
Wikipedia contributors. “Software development effort estimation.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 22 Aug. 2012. Web. 17 Sep. 2012.
Wikipedia contributors. “Program Evaluation and Review Technique.” Wikipedia, The Free Encyclopedia. Wikipedia, The Free Encyclopedia, 6 Sep. 2012. Web. 17 Sep. 2012.