One thing to keep in the back of your mind is the definition of an estimation. An estimation is a prediction of the future and therefore cannot be 100% accurate. There is no way of avoiding this. The only way to truly find out how long something is going to take is to actually do it.
With that in mind, let’s examine some of the well known approaches to estimating software. I will start with the least time consuming approach. This approach carries a lot of risk but there are some circumstances where it can be beneficial. So, similarly to knowing which is the best tool to use for a job, only use this approach in the right circumstance or you can get yourself into a lot of trouble.
1. Bracketing
Bracketing is a very quick way to get an estimate for a software project and can be used to help answer that dreaded first meeting question; how much will this cost me? A question that can also sometimes be disguised as; how long will this take?
The basic idea is this, you will need to come up with some brackets and then, using your best judgement, put the project into one (or more) of those brackets. You can think of this as something like t-shirt sizes. For example, some brackets I have used previously are:
- Less than $100k (Small)
- Between $100k and $500k (Medium)
- Over $500k (Large)
By having a broad range like this you are increasing the likelihood of being correct. However, the perception of the person receiving the estimate has to be carefully managed. Usually this technique is used only very early on in a project, to see if the client and software provider’s expectations are aligned. For example, if someone is asking for something sophisticated to be built and it is clearly a large project, you can say it is in the Over $500k bracket. However, the person may have been hoping for or expecting the Less than $100k bracket. Identifying this mismatch in expectations early can prevent a lot of wasted time. It may also lead to some conversations that are hard now, but would be far more difficult later and so must happen.
One last note on this approach; be careful with how you deliver your estimation in a meeting when you use brackets. I have experienced people still hanging onto the dollar amount (bracket) for a significant period of time after the project has kicked-off, despite a number of changes to the original project scope.
2. Relative Prediction
A relative prediction uses the past to predict the future. The idea is to use projects that have been previously delivered, and then use your judgement to say how much bigger or smaller this project is.
Relative predictions can raise all sorts of questions, including what considerations should be used to work out whether the current project is of a similar size or not. At this point, I would say to use the force (your gut instinct). If you want to get more detail on the estimation, you are probably better off using one of the techniques that require more effort. There is little scientific proof to suggest that relative estimations are not more accurate than absolute estimations.
There is a reason I like relative estimations and that is you get to show the customer (or person you’re selling the idea to) other projects that have been completed. This is a great way to build trust. And when combined with bracketing, it can be a very powerful sales approach. In a meeting, you can show a really cool project from the same bracket that you believe the new project will resemble.
3. Multiple Experts
An improvement you can make to your estimations is to use multiple experts. Two heads are better than one! When you have multiple experts you can introduce ways to reduce risk. For example, using the group average for an estimation can have benefits.
Actually, using a group average is a technique that I learned in the military when estimating distances. If you want to know how far away something is, you have everyone write down their estimate on a piece of paper and then take the average of the estimates. If you have more people you could drop the highest and the lowest and then average the rest. It was surprising how accurate this method was simply by eliminating outliers and settling on something reasonable. Multiple experts can be combined with both bracketing and relative prediction.
Another way to use multiple experts is to use the Delphi method. This method was first experimented with in the 1950’s by the United States Airforce on the use of experts for the estimation of bombing requirements. It has been improved upon since then but the general concept remains the same. It requires you to ask the experts to estimate (and justify this estimation) without communicating with the other experts. A facilitator would then anonymously share the others estimates and justifications and ask everyone to adjust their estimations in a second round. This process may continue for several rounds. Some of the concepts of the Delphi method are used in modern estimation techniques like Planning Poker (discussed below).
4. Work Breakdown Structure (WBS)
A work breakdown structure (WBS) is a hierarchical approach that incrementally decomposes a project into phases, deliverables and work packages. It uses the 100% rule to ensure all work on the project is in scope and that each element of work is mutually exclusive from the others to minimise overlap and miscommunications.
Personally, I like the ideas around decomposing the work into smaller parts and this technique is used in many modern approaches. However, the WBS approach leans itself towards older waterfall software development methodologies and it can create friction when applied alongside Agile. The 100% rule that requires everything to be included in the scope is at odds with the Agile manifesto which advocates for working software over comprehensive documentation. Would you want to use WBS? My guess would be no, but it is worth acknowledging it as a technique.
5. Planning Poker
Planning poker is an estimation technique used by Agile software teams and is very popular with Scrum. In 2002, James Grenning introduced Planning Poker or How to Avoid Analysis Paralysis While Release Planning. The game goes like this:
Each player has a deck of cards 1, 2, 3, 5, 7, 10 days and infinity. A customer deals a story and the players have some time to absorb the story. Then all players roll’em simultaneously (reveal their choice). The estimators at the extremes of the values begin the discussion and they all come to a consensus on the result. An infinity card is played if estimates are over 10 days.
The planning poker method gained popularity as it gave everyone experience at estimating and the whole team got to play and contribute. Mike Cohn developed planning poker further, into a method that can be found in his book on Agile Estimation. In chapter 6, Mike writes about techniques for estimating, and the reasons he likes planning poker. My favourite is his last reason, “Finally, planning poker works because it’s fun.” I have to agree - bringing fun to work is great for all involved!
6. Planning Game
The planning game is used for practitioners of Extreme Programming (XP) and is aimed at addressing two important questions; What will we accomplish by the due date? What will we do next? The planning game has two planning steps: iteration planning and release planning. The iteration plan is where the customer presents the stories for the next iteration and the release plan is more high level and therefore necessarily imprecise.
You can play this as an actual game as well and it is designed to be playful, fun, and inclusive of the whole team (including the customer). The XP game explains that it is started by opening a magic bag of props including cards, dice, paper, balloons, etc. The stories are unpacked by a customer and the team has a time-box to work on the estimations.
7. Codebots Software Estimations
The Codebots software estimations are a technique that we have developed based on our way of working. It is a technique that has evolved over many years from facing real world challenges and delivering projects we have estimated. By experiencing the good, the bad, and the ugly, several mechanisms have been placed within our technique to help ensure we have successful projects and are able to manage people’s expectations.
The approach uses ideas from existing and known estimation techniques (like the Delphi method) but introduces some new ideas as well. In its current incarnation, it uses hours and not story points for estimations. So, it could be a good choice if you are looking for an alternative to story points based approaches.
It has a focus on acknowledging and dealing with risk. There are also several allocation factors that make the estimations more realistic as it is more in tune with how projects really play out. If you are reading this article via the Codebots library, there is a course in the academy that teaches you the ins and outs of this technique. If you are reading this as part of the course, carry on reading to find out more!
Summary
There are many more estimation techniques than the 7 listed in this article. The first 3 (Bracketing, Relative Estimations, and Multiple Experts) can be used in combination to get through some of the those initial first meetings before you have had a chance to spend significant time scoping a project.
There are more detailed approaches such as the WBS, which is about decomposing the work into smaller tasks. But WBS is quite an old technique and may not be relevant for you today. The more modern approaches including techniques like Planning Poker and the Planning Game. Both techniques bring a little fun to the process but put in safe guards to help the estimators come up with a good result. These are very good approaches.
The last estimation technique, Codebots Software Estimations, is one that we have developed, used internally, and trained people to use on their own projects. It was born out of a process where hours were emphasised (instead of story points) and where we wanted to take into account the uncertainties and realities associated with building software. I like to describe it as coming out of the fighting pits of Sparta, as it has been the result of many battle scars. Recently, we have been making far less changes to it as it has settled into an approach that has produced many good estimations with projects running on schedule and people’s expectations managed.
Finally, if you are interested in reading more on software estimation techniques, Jørgensen (in his book on time predictions) dedicates chapter 7 to Time Prediction Methods and Principles. He groups various estimation techniques into the following 9 groups. It is well worth reading through his analysis of the various methods and principles. The 9 groups are:
- Unpacking and Decomposition
- Analogies
- Relative Predictions
- Time Prediction Models
- Consider Alternative Futures
- Combinations of Time Predictions
- Let Other People Make the Prediction?
- Removing Irrelevant and Misleading Information
- From Fibonacci to T-Shirt Sizes: Time Predictions Using Alternative Scales
It is well worth reading this chapter!
Written by Eban Escott
Founder of Codebots
Dr Eban Escott received his Doctorate from UQ (2013) in Model-Driven Engineering and his Masters from QUT (2004) in Artificial Intelligence. He is an advocate of using models as first class artefacts in software engineering and creating not just technologies, but methodologies that enhance the quality of life for software engineers.
