Estimating the length of a software project is notoriously difficult. As discussed in Activity: Managing expectations, there are many risks involved so having a robust estimation process is essential. There are a number of different ways to go about estimations and you will find some similarities here with other methods. One key difference is that we use risk to influence our estimations. We also use some other factors that attempt to better match the estimation to reality.
Before you start
The requirements backlog must be up to date. If you do not have a requirements backlog, follow the Activity: Reverse Engineering Requirements activity. It is also recommended you have already run the Activity: Managing expectations activity.
Details
Level of difficulty
Hard
Stage
Prepare
Suggested time
1-4 hours, depending on the size of the backlog.
Participants
- Squad lead
- Designer
- Web engineer
- Test engineer
Materials
- Spreadsheet
- The Codebots Platform
Steps
- Access the story estimation spreadsheet. Open it, save a copy and have a look around.
- Fill in the user stories on the sheet. These are the rows in the table below.
- Put the squad members across the top as the columns. It is recommended a minimum of 3 team members.
-
The squad lead will choose a story to estimate. Without discussion, each squad member is to write down their estimation. The choices for the length of the story is a fibonacci-like sequence shown below:
- 1 hour (0.13 days)
- 2 hours (0.26 days)
- 4 hours (0.52 days)
- 8 hours (1.05 days)
- 16 hours (2.11 days)
- 32 hours (4.21 days)
- 64 hours (8.42 days, 1.68 weeks)
- 128 hours (16.84 days, 3.37 weeks)
- 256 hours (33.68 days, 6.74 weeks)
- 512 hours (67.37 days, 13.47 weeks)
-
The next step is to assign a risk level to the story. The risk is based on unfamiliarity and complexity.
- After each squad member has their time and risk estimates, the squad lead can facilitate a discussion and the squad can listen to different justifications and change their estimations if they want. However, stick to your guns if you need to! Go back to step 4 and repeat for all the stories.
- The last step is to analyse the summary found on the last sheet and shown below.
Justification
Any person that has dealt with computers knows to expect the unexpected. For example, a software engineer can be doing a task and complete most of the work very quickly in a few hours, then some very strange behaviour happens and they spend the next 3 days trying to debug and figure out what the heck is going on. This is not a reflection on the person’s ability. After you have spent many years in the trenches you come to the realisation that this is very complex work that carries a lot of risks. This is a major source of frustration and is one of the reasons why doing estimations can be an agonising process. It is the unknown unknowns that will inevitably spring up when the development is underway.
We use time rather than a points-based mechanism to estimate an iteration. When we estimate time we do so on the assumption that the squad members responsible for completing the work have reached a standard level of proficiency. For example, a web developer is qualified on using the JavaScript MVC framework and they are able to create a custom tile, view, or component within a timeframe because that is what they are qualified to do. If a developer is faster at completing a task than what was estimated, then this time is saved on the overall project. For this reason, stories are estimated on typical qualified squad members.
Written by Christine Chien
Marketing Operations and Partnerships
Our very own Christine is a marketer by day, nerd by night. If she isn’t developing our marketing strategy, she is usually found by her 3D printer or at a local plant shop.
