Why estimate user stories
This article explains why it is necessary to estimate User Stories and what types of estimations are in use.
Why Estimate User Stories
Imagine having a new customer that wants you to implement a new product quickly at best quality and modest cost. It might be possible to try to estimate the task immediately, evaluate the product offhand, and work out temporal and financial assessments of the project, promising to take into account all the wishes. However, such an approach entails a high risk that the product will not be implemented within the specified timeframe, will exceed its budget, and will not meet the customer’s expectations.
To avoid mistakes, it is first necessary to make sure that you and the customer are talking about the same features. To this purpose, a project charter is formed that ensures mutual understanding of functionality among all the project participants; the project functionality is divided into smaller pieces. At this stage, the development team and the customer look together through project details and come to an agreement regarding the project content.
The next step is to create User Stories for the product backlog.
The development team, being the end performer, can estimate each story separately. The sum of those estimations makes for an approximate implementation time for the whole project. This a more precise approach, because it includes detalization and it shows what features are to be excluded in order to meet possible deadlines and to remain on budget.
Later on, when the time estimation is done and you have met an agreement regarding project functionality, the User Stories can be combined into epics, a roadmap can be designed, the customer can be provided with the cost and time estimations.
The project’s destiny will depend on how accurate the User Stories have been estimated.
How to Measure a User Story
ABSOLUTE TIME ESTIMATE
(Some people feel like using ideal days here, ideal hours, or just man-days or man-hours.)
Advantages of this estimation method:
- It is simple and clear in terms of time. Once it is said to the customer, they easily perceive it. For example, feature 1 can be implemented in three days, feature 2 will take fourteen more days, etc.
- The estimate can easily be converted into money: 1 developer’s hour costs $200. The functionality whose implementation takes 3 hours will cost $600.
- Velocity. If the team consists of 6 full-time developers working 5 days a week and 8 hours a day, then we know that their velocity for a 2-week sprint is 6*5*8*2=480 hours. Provided the development team estimates all User Stories as 5500 hours in total, it is reasonable to expect the project completed within 6 month.
Disadvantages of this estimation method:
- The initial User Stories might not be accurately estimated. For example, the first story had been estimated at 20 hours, but in fact it took 40 hours to be implemented. If the team estimates other stories relative to the first story, then all estimates will be wrong. In projects where Gantt charts are used for visualization, the managers will have to recalculate everything from the beginning.
- People cannot accurately allocate absolute units of measure. There are many popular studies conducted on this topic.
STORY POINTS AS RELATIVE VALUES
T-shirt sizes (XS, S, M, L, XL) and other abstract points can be mentioned as good examples.
Advantages of estimation in SP:
- SP are relative, and this fact mitigates the impact of misestimation. For example, the whole backlog was estimated at 5500 SP. When implementing one of the initial stories, which was estimated at 8 SP, the team realized it took 12 hours, not 8. So, should they re-estimate everything? No, because nothing serious has happened. Despite the velocity decrease and the fact that the next sprint will include fewer user stories, the complexity estimation of the story, in comparison with the other stories, will remain the same.
- For example, a story is estimated at 2 SP. A senior developer can implement it in 2 hours. On the other hand, it can take 4 hours for a junior developer. Nevertheless, in comparison with the easiest User Story, estimated at 1 SP, the given story will be found twice as complex as the easiest one by both developers. In this case, both developers will mutually agree on the 2 SP estimate.
Disadvantages of estimation in SP:
- SP’s seem incomprehensible for the customer. If one tries to explain that a specific feature costs 8 SP, the customer won’t understand it. And it gives occasion to them to try to pay 8 foobars for that job!
- The real coefficient of proportionality between one SP and the time it takes, including the velocity value in SP’s, will only become reliable after 3 or 4 sprints.
- SP values vary from team to team. That’s why it is hard to compare SP’s by multiple teams.
What to Choose for the Project?
- In short-term projects, it is prudent to use the conventional time-based estimates. They are transparent to the customer and can be easily assessed in terms of money.
- In long-term projects, it is better to use Story Points. At the beginning of the project, it is easier to figure out a complexity ratio between the simplest story and stories that will only be implemented half a year later, rather than trying to estimate all the stories in hours.
- At the initial stage, it is as well possible to test converting Story Points into money. Just estimate the easiest story in Story Points, then estimate it in units of time and convert the resulting estimate into units of money. But, please, be advised that the exact cost of one Story Point can only be figured out by the end of the 3rd or 4th sprint. That is why such a method of estimation should not become a common practice.
In the next article we will explain why it is necessary to estimate user stories’ subtasks, and how it is done.
