Effectively matching estimation to reality.
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.
Level of difficulty
1-4 hours, depending on the size of the backlog.
- Squad lead
- Web engineer
- Test engineer
- The Codebots Platform
- 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.
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.