Delays in the implementation of an IT project are everyday life for programmers and project managers. What are the reasons for errors in estimating the necessary time and how to avoid—both in Scrum and outside of it—incorrect estimations by using the story points methodology?
The typical method of evaluating the time needed to implement a project, used by most development teams, is based on time estimates (e.g. man-days). This almost always results in exceeding the planned implementation deadline (mainly because of too optimistic assumptions in terms of work efficiency and task complexity). To put it simply, the teams always think that they are going to be ready sooner than they actually are. Incorrect time estimates mean higher costs of project implementation, i.e. exceeding the budget.
Table of Contents
Story points
The story points methodology used in Scrum enable correct estimation of the necessary workload. It also makes it possible to avoid a situation where it turns out that the original assumptions are nowhere near reality and the entire estimation is inflated. How does it work?
What is the idea behind tasks estimation in Scrum based on the story points methodology?
In order to understand the story points methodology, a few concepts need to be explained. The fundamental part of every IT project is the list of items to be completed (product backlog). Completing every item requires time and effort from the programmer(s) and the rest of the team. The time depends on how complex, comprehensive, etc. the task is. In order to estimate tasks, a special unit is created: a story point, which represents an abstract volume of work. The sum of story points equals all of the work that needs to be done in order to complete the project.
Each item is assigned a specific number of story points. The assignable values are defined using a Fibonacci-like sequence (0.5, 1, 2, 3, 5, 13, 20, 40, 100). The rounding shows that this is estimation and not a specific value and allows avoiding potential inflation of points. This is because if specific values were used, the team could for instance argue for an hour whether the given task has 23 or 24 points.
Why are story points better than simple time estimation?
First of all, because their abstract nature allows to avoid underestimation due to optimistic evaluation of time (it’s easier to say that the given item will cost 10 points than that it will take 6 hours of work). Also, story points take the complexity of the task into account, like the case of tasks that require a relatively short code, but need lots of thinking or are very exhausting.
Estimation based on story points in practice
- Team meeting.
- Discussion on the user story and its details.
- Individual estimation, with everyone making an estimate without revealing it.
- Once every team member has made an estimate, everyone simultaneously discloses the values they assigned.
- If team members agree as to the value, the user story is assigned the given number of points. If not, the team negotiates and goes back to point 3.
Measuring efficiency in the story points methodology
This method allows tracking efficiency thanks to counting and summing up story points when iterating items. In order to monitor efficiency, it is also necessary to set up a quality gate to make sure that efficiency is not increasing at the cost of more errors. Often, at the beginning of implementing the story points system, there is a discrepancy between the planned number of story points in a sprint and the actual number of completed story points. With time, the team learns how to properly estimate the number of story points to make sure that work is going on smoothly.
What causes the inflation of points (i.e. wrong estimation of tasks)?
- Different understanding of story points (as a unit of work) by particular team members
- The bigger (more complex) the task, the higher the inaccuracy of estimation
- The team not taking into account metrics and historical data
- Changing the value of story points during project implementation
- Not tracking velocity, which may result in decreased quality and the need to use more story points in successive sprints
What good practices in terms of estimation help to avoid the inflation of points?
- In order to complete the estimation, all team members must agree on the value of story points. If different people understand the unit differently, the estimation will be ineffective.
- When specifying the value of an item, creating a reference task may help. This is an example of a task that serves as a reference point for other tasks to estimate the number of their story points. You need to remember that the reference task must be understandable and easy to refer to for people with various competencies that make up the team (JavaScript developers, database programmers, testers). A good example is the implementation of a simple change to the production environment. This means a small change that can be implemented without advanced testing. The idea is to make a real estimate and refer to other tasks on this basis.
- The task should be divided into smaller elements in order to reduce underestimations.
- Data from previous sprints should be collected and historical data should be used to estimate new user stories.
- It’s a good idea to keep the value of story points constant across the entire project implementation period. This assumption is usually abandoned when there is pressure to carry out a higher number of points in a sprint.
- Velocity needs to be examined and analyzed, drawing conclusions for planning story points for the next sprints.
- Planned disruptions (such as employee holidays) also need to be taken into account.
Finally, the basis for reducing the inflation of story points is remembering that they do not reflect any particular time value, but are a representation of a normal distribution and as such, they will always be subject to certain deviations.
