Story point – a revolution in task estimation? part. 1

A new idea

Ever since the idea of estimating project requirements in a way separate from the classic man-days appeared, many people have been skeptical about abandoning the beaten path. In addition to the force of habit and simple logic, there were voices against changing the approach to the so-called story points indicating the inability of converting a point into money or work time control based on story points. Opponents cannot be denied the rationale. Conversion of abstract units used for estimation is neither obvious nor simple, as is the traditional understanding of authority and control that does not occur in Scrum.

Faulty estimates

Why, therefore, give up on the current way of settling tasks, which verified according to the managers? What is wrong with estimating labor consumption in days and hours?

Both units (man-days and story points) are good, but they relate to other values and, consequently, they can bring different benefits in specific situations. It is worth realizing that time estimation, however, has some disadvantages, of which you can read below.

First, the estimation based on a specific time allows you to calculate accurately the cost of work. This precision, however, can be a trap. Determining the exact project estimate before it starts can be fraught with errors. It is extremely difficult in an unknown organization, in a new team and with requirements for a new system. If we add a fixed project budget or a fixed price settlement model, our sense of control is simply illusory.

Second, “clean” estimates in business days do not take into account many factors that can happen. Some of them can be predicted, such as, typical project risks, changes in the implementation of requirements or planned holidays, but we will not predict everything. Estimation of labor consumption in days defines one, specific variant of the workflow. Possible overheads are usually not very precise, sometimes they are parameterized, but most often they dependent on subjective estimation.

Thirdly, time estimates do not operate in a vacuum. They always have a reference point. The selected person compares the estimated task to tasks performed in the past and by analogy, determines the time needed for their implementation. Figuratively speaking – an experienced team leader knows that his team performed the given task in two days, so he accepts this “valuation” in the current project. Reality may turn out to be completely different.

Control, which results from precise time measuring, is often overused. In a project you can find many pathologies, for example, forcing the delivery of an element after the first few days, creating artificial rivalry between teams or forcing under-estimation. Such micro management, fueled by the estimation of work in units of time, does not make any sense in Scrum. It ruins the atmosphere in the team and proves that the manager is poorly prepared for his role.

Alternative

For people who have no experience in agile management methodologies, it is worth explaining what the story points are. Mike Cohn – one of the contributors to Scrum, defined this concept in the following way: “Story points are a unit of measure for expressing the overall size of a story, feature, or other piece of work.”

What is worth remembering is the information that story points do not refer to the time consumption of a task, but to its size! My favorite comparison showing the separation of the size of the task from its duration is an example of eating pizza: We have two people sitting at a table. One of them had not eaten anything for two days, the other one had eaten a two-course dinner just now. If we put two pizzas in front of them, measuring the time will indicate that the second person (full) will eat the pizza for an hour, while the first one (hungry) will eat it in ten minutes. The story point focuses on the size of the pizza, which in both cases is the same.

Story point got its name from the form of requirements to which the estimation is used, i.e. user stories. To simplify it, the user story is a way to formulate product requirements from the point of view of value for the end user, it is created with a specific narrative and requirements for the approach to writing them. If you want to learn more on this topic, I recommend the book :User stories applied by the above-mentioned” Mike Cohn.

Story point without flaws?

Coming back to the example with a pizza: why do we need to know the size of a pizza if we are interested in how fast someone will eat it? The case presented here makes sense when we know in advance who will perform the work, for example in a situation where a given specialist works alone. In the case of a team of three to nine people (Scrum Guide recommendations) with complementary competences, the calculation of the whole project in advance, based on specific persons, carries a considerable risk.

Thanks to the estimation in story points, we first determine the size of the task. We define the period of its execution, e.g. in one sprint, during sprint planning, when a team member undertakes to do this work. Measuring labor consumption instead of time better defines risks and changes in decisions. A story point means the relative size of the challenge. Such a perspective allows to better control the issue of risks and uncertainty.

In terms of micromanagement, a user story estimated using story points and accepted by the team and the Product Owner as part of the sprint create a commitment to perform this task on the team’s side at the end of the sprint. This form of commitment shifts the burden of responsibility to the team and guarantees greater freedom of action. Comparing the speed of two teams, e.g. comparing who provides more points per sprint, is pointless, because the point has the value that a given team will give it. Team A producing 50 story points per sprint, can do the same work as team B producing 12 points. The difference is due to the fact that team B has taken more work as a reference point.

Story points are an attractive alternative to time estimation. I have explained the difference between the two approaches, which in practice are understood differently. The correct understanding of the advantages and the approach to agile estimation does not mean yet success in implementation, but it makes us aware of why this change is needed.

The implementation of story points is worth considering for a number of reasons. However, you should remember about such elements as the team’s maturity or potential disadvantages of this approach. In the second part of “Story point – a revolution in task estimation?” I will discuss conditions in which the story points perform better, and in which worse. I will also discuss the issue of the Critical Path in relation to story points.