The last of four (4) additional Implementation Topics of Interest provides guidance on how to effectively estimate the amount of work required to complete a Feature or Story.
Overview
Size estimates are critically important from a planning and delivery perspective. Because all planning and delivery relate to certain time boxes - Sprints and Releases - knowing the amount of work that can fit into each box plays a huge part in determining whether efforts planned for the given iteration will be successful. Put too much into a box, and items won't get "Done" as planned. Expectations will not be met. Put too little in a box and supplemental planning and management tasks will be required to keep things moving. Neither of these leads to effective delivery.
Estimate Stages
Depending on the level of understanding required at a given time (i.e., how far is the Feature or Story on the horizon vs. how close to being included in a Release or Sprint) its estimated size may go through three (3) stages:
- Preliminary, Relative Estimate – In some cases an initial, rough estimate will suffice. At this level, relative estimating can be used to compare the "bigness" of one Feature or Story to another. A Fibonacci approach works well because with each increase in size, a certain amount of uncertainty is automatically built into the estimate.
- Gross, Absolute Estimate – The relative estimate above is fast and straightforward, but the increasing range in the relative Fibonacci numbers can leave some pretty big uncertainty in the prioritization. To take the next step in reliability, or to get a quick estimate of potential costs, use an historical comparison. This compares the new Feature's size to the Story points required to deliver comparable Features in prior iterations. Or a new Story's size to the points required to completed a comparable Story in prior iterations.
- Derived, Absolute Estimate – Finally, when the reliability of an estimate needs to be further improved, the Team can break the Feature down into Stories, and estimate the individual Stories. The sum of the Story estimates by the Team creates the most refined estimate of potential scope and cost for the Feature.
Estimate Objective
Recognize that estimates are for the amount of work the Team will have to perform, not just work a Developer or Configurer may need to do.
Some changes will include a lot of development time and relatively less testing time. Other changes may require only a small change, but that change may affect a large scope of testing.
Some changes will be the first time through and require additional work, such as the creation of Operating Procedures, while other changes will build upon earlier efforts and only need minor revisions to existing content.
Regardless of the balance of work among the various Team roles, the estimate should be for the amount of effort required of the Team, not any one member of the Team.
Estimating Stories
Stories are estimated using a "Points" size estimate based upon either:
1) Preliminary, Relative Estimate (i.e., Fibonacci based estimate); or
2) Gross, Absolute Estimate (e.g., comparison to prior work estimate).
as described above. Â Depending on accuracy required at a given time (i.e., how far is the Story on the horizon vs. how close to being selected into a Sprint) the estimate may be revised.
Use the low-end of the Fibonacci scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233) for estimating Story Points.
While Story Points are not intended to represent hours of work, it is a good place to start the basis for estimating. Consider the most basic, simple change that could be made to the Solution. For example, re-labeling one field on one page from "Address" to "Location", without any other corresponding changes to the field itself or any code related to it. Just the label.
Consider the amount of time the Team will take (not just the Developer) to select the Story for work, to make the change, to validate the change, to progress the change through its build cycle and to demonstrate the change in order to gain 'Acceptance' of it. This most basic change would take about 1 hour of the Team's time. So, give it a corresponding Story Point estimate of 1. And then scale from there.
Depending on the complexity of design, implementation and testing, the Story may be estimated only by the Solution Owner or, more typically, will also include input from Team members.
Estimating Features
Features are estimated using a "T-Shirt size" estimate based upon either:
1) Preliminary, Relative Estimate (i.e., Fibonacci based estimate);
2) Gross, Absolute Estimate (e.g., comparison to prior work estimate); or
3) Derived, Absolute Estimate (i.e., sum of related Story Points)
as described above. Â Depending on accuracy required at a given time (i.e., how far is the Feature on the horizon vs. how close to being selected into a Release) the estimate may be revised.
Similar to Story sizing, Features are sized relative to one another. However, Features use a concept of "T-Shirt sizes", rather than "Story Points". As Features are larger than Stories their Fibonacci baseline begins at a larger number and scales from there.
Depending on the complexity of design, implementation and testing, the Feature may be estimated only by the Solution Owner or, more typically, will also include input from the Business, Team members, 3rd Party Solution Provider (where applicable), Enterprise / Solution Architect, QA and DevOps.
If the estimate of any related Story changes, review the Feature size to determine whether the new size changes the Feature from one T-Shirt size to another. If it does, assess the impact to current or planned Releases.
T-Shirt Size to Story Point Size Mapping Guide
The table below provides a recommended guideline for mapping Feature T-Shirt sizes and Story Point estimates.
|
T-Shirt Size
|
Story Point Equivalent
|
|---|---|
| XXS | 13 Pts |
| XS | 21 Pts |
| S | 34 Pts |
| M | 55 Pts |
| L | 89 Pts |
| XL | 144 Pts |
| XXL | 233 Pts |