By Tessa Holland and Mikaela Robertson 14 January 2020 Way of Working
An outline of the Codebots estimation process.
The estimations which are provided to customers offer a plan for the project, taking into account the difference between an ideal time estimate and a realistic estimate. Our recommended estimation method takes into account past project experience, the project's complexity and it's risk.
Before beginning estimations, you will need to set up the estimation tool. Clicking on the link will create a new copy of the spreadsheet inside your drive.
In the Backlogs tab, enter all the user stories you defined in the capturing requirements phase. List your epics in the 'buckets' column and the stories in the 'summary' column. You can add any additional notes that will aid your estimation accuracy in the 'notes' column. In the top right corner, enter the number of estimators participating in the session. This will update the number of columns available to enter your estimations.
A set-up spreadsheet may look something like this:
For each story, read through the user story, background, acceptance criteria and implementation notes before estimating. If any additional technical notes arise during the discussion, take note of them in the backlog.
Our time estimation values follow a Fibonacci-like sequence. This is a standard practice in agile estimation processes to ensure that developers don't get too caught up in a getting a specific time, and instead focus on the general size of a task.
Each estimator should estimate based on how long the entire team will take to complete the ticket. That is, the estimate should reflect the longest duration it will take a team member to complete the ticket.
Enter each team members' estimation in the 'Time Estimate' column under their name.
If the time estimate is longer than 2 days (16 hours), you may need to break the story into smaller parts.
The more complex and unfamiliar a story is, the higher the risk that the development time will be underestimated. To ensure that the risk is appropriately considered in your estimations, two multipliers are included: unfamiliarity and complexity. Both multipliers are quantified with a number rating between 1 and 5.
The unfamiliarity multiplier takes into consideration the unknowns of the project. Team members should consider the experience, available resources, and whether it uses new or existing technologies. For example:
- If the developers have worked with a piece of third-party technology before and are quite confident, then the unfamiliarity score would be low (probably one).
- If the developers haven't worked with the technology, but someone else in the company has, then the unfamiliarity score would be moderate
- If no-one in the company has ever worked with the technology before, then the rating would be quite high (probably five).
The complexity multiplier quantifies how intricate and challenging the task may be. The team should consider how many other parts of the product are affected by this task, how complicated the development will be, and how likely this requirement is to change. For example:
- If the story uses a feature which has been developed in the past and it won't require any changes, then the complexity would low (probably one).
- If the story can use an old feature, but it would need modifications to meet the requirements, then the complexity score would be moderate
- If the story requires completely custom development and extensive testing, then complexity score would be quite high (probably five).
These two factors are multiplied together to get a risk score out of 25. As a rule, a story cannot enter into a development iteration unless it has a score of eight or lower. If the risk is too high, a tech spike will be needed, or the story should be broken down into smaller components.
Enter each member's unfamiliarity and complexity scores into their column in the spreadsheet.
Once you have entered the time and risk estimates, your spreadsheet may look something like this:
In addition to the time and risk estimates submitted by the team, three other factors impact the final estimation figure. These factors are already taken into consideration by spreadsheet algorithm, so there is no need to consider them while giving estimation figures. (In the spreadsheet, these factors can be changed in the summary page)
Activities such as meetings, assisting colleagues and alternate side projects take up their time and should be recognised when estimations are being considered. In our process, this is done by applying what we call an allocation factor, which assumes that any development team is able to work on active development for 80% of their time.
Trim the Tail (Iteration N)
The trim the tail allowance is used to add a chunk of time into the project to account for any bugs or minor improvements which may pop up. The trim the tail factor calculates a period of time which can be used throughout the project's timeline. This creates a bank of time which can be drawn from at any point. When the squad lead and the project manager agree it is required, the standard development progress can be paused, and the team can enter into an iteration N.
Similar to the trim the tail allowance, the tech spike allowance creates a bank of time which can be drawn upon when the development team needs it. The tech spike allocation is used as a chance for the team to take time to research or test concepts.
In the 'summary' tab of the spreadsheet, you can see the final estimations, factoring average team estimate, risk, allocation factor, trim the tail and tech spikes.
In this example, the summary shows an estimation of 6.53 weeks.
Cone of Uncertainty
The Cone of Uncertainty is a depiction of the level of uncertainty around the length of time required to complete a project based on the amount of knowledge at the beginning of a project, and the risk of the project time blowing out due to this uncertainty.
In the example, the Cone of Uncertainty shows that the project could take up to 9.38 weeks if all Trim the Tail and Tech Spike time is required. These figures can be used to set more realistic expectations.