How do you estimate a software project? It is possible to calculate a decent estimation of a software project (as long as you are willing to put in some effort). Previously, we have covered 7 ways to estimate a software project, but in this article we are going to dive into the details on how to follow the Way of Working and use a time estimation spreadsheet. If you like this approach, you can download the time estimations spreadsheet for yourself. The following screenshot is what the Summary page of the spreadsheet looks like.
Summary with Totals
In the summary, the first section is the totals. The totals include the initial estimations with allocation factor (cell B6), the additional Trim the Tail multiplier (cell E6), and the additional in Tech Spike factor (cell H6). The initial estimations are calculated on a different sheet, and just displayed here.
How do you calculate man hours for a software project? They are determined by the scoping team estimating the time units they believe are required to complete each user story in the project. Our time estimations follow a fibonacci-like sequence, as recommended for agile software development. Our sequence is 1, 2, 4, 8 hours, etc. You can read more about how you estimate a software project in man hours in another of our articles.
This initial estimate also includes an “Allocation Factor”. The Allocation Factor is an acknowledgment that in any workplace, employees cannot possibly dedicate all of their time to their primary role. Meetings, assisting colleagues, and alternate side projects can take up their time and therefore need to be recognised in estimations. To account for this, the spreadsheet assumes the development team will be able to dedicate 80% of their work week to a project. Therefore the estimations are multiplied by a factor of 1.25.
We then add our time for “Trim the Tail”. This is our time allocation that is needed in a software project to account for bugs and minor improvements that may pop up. The Trim the Tail is calculated by a multiplier of 1.25 on the original time estimate. You can see the amount of time this brings the estimation to in cell E6.
In the last row of the summary we add in time for any “Tech Spikes”. A Tech Spike allowance is used as a time bank for the development team to draw upon when they need to take time to research or test concepts. This is useful when a user story is particularly complex or unfamiliar to a project team member. Adding in tech spike is calculated by a multiplier of 1.1 (i.e. adding 10% to the project time).
You will then be able to see the total estimate of time for the software project (cell H6).
Summary with Cone of Uncertainty
The second section we add in our calculations takes into account the Cone of Uncertainty. What is the Cone of Uncertainty? We have previously covered the Cone of Uncertainty in our articles on Managing Risk. As a brief summary, it is a calculation that helps us depict the level of uncertainty around estimating the length of time required to complete a project. This uncertainty stems from the limited knowledge at the outset of a project, and the risk of the project time blowing out due to this uncertainty. Therefore, the longer we try to predict out a project, the less certain we can be of the timeframe.
To account for this uncertainty, we use the following calculation in our estimation spreadsheet to work out the Cone of Uncertainty multiplier: (([initial estimation]^2+[initial estimation])/2)/100 (see cell B9).
We then repeat this formula on our calculations for Trim the Tail and Tech Spikes in the spreadsheet summary. As you can see on the example, our total estimate now has an increased 2.19 weeks maximum.
Summary Breakdown
The Summary Breakdown summarises the multipliers used throughout the spreadsheet (Allocation Factor, Trim the Tail, Tech Spike, and Hours per day) so that you can change them as required. It also lists any High Risk Issues and High Time Issues that have arisen during the team’s estimations on the requirements backlog sheet.
The Breakdown pulls these issues from the Backlog sheet. High Risk Issues are any user stories with a risk over 6 (though you can change that value if you want). We have previously covered calculating this risk score based on familiarity and complexity. High Time Issues are user stories that have been estimated to take longer than a working day to complete (7.5 hours by deafult).
It is important to draw attention to these user stories so that stakeholders can view the estimations and understand any requirements that have caused the estimations to blow out, as well as any requirements that may need to be more carefully managed during development.
How do you calculate development time? If you download the time estimation spreadsheet, all of these calculations will be completed automatically, provided you estimate your backlog. However, it helps to have an understanding of how and why these numbers have been reached.
Written by Jordi Kitto
Software Developer
Jordi developed this very site you’re on right now! And when he’s not working on this site, he is showing off his latest Apple products to everyone in the office, or working on his side hustle
