Estimating the work in Scrum and evaluating how much time it will take to implement all the items and all User Stories from the Product Backlog is extremely troublesome.
This task can be difficult for many teams, particularly those without experience using Agile methodologies and frameworks (Agile, Scrum).
The problem of estimating working time is complex. We wrote about this issue in the article "How to estimate the work of Backlog elements."
When the development team tries to estimate the working time, it needs to be aware that the accuracy and reliability of this estimate depend not only on knowledge and experience but also on a series of factors, including external ones, which aren't always considered.
Of course, the situation is not hopeless. There are many techniques for estimating the working time needed to implement the various elements of the Product Backlog.
In the article mentioned above, you can find descriptions of some of them.
In this article, however, we will focus on a very popular and useful technique that is eagerly used by development teams due to its advantages.
If you don't know what Story Points are (the Agile-specific measuring units), then be sure to read this article.
What are the Story Points? Why are they so popular, and why are they used so eagerly by teams working in agile methodologies? How to estimate story points?
Why is it worth using Story Points to estimate work? What does the estimation of working time with the help of Story Points look like?
In just a moment, you will learn the answers to these questions and discover more details about one of the most popular techniques for estimating working time.
We cordially invite you to read on!
Are You Interested In The Product Concept?
Why is the estimation of working time so problematic?
Let's start with the issue that seems quite obvious but at the same time weighs on everything. It impacts deadlines, efficiency, final quality, and competitiveness of the digital product.
The ability to make the most accurate, close-to-truth estimation of working time is essential to the project's success.
This means ensuring that it is executed within the set timeframe and budget and in accordance with the complex and diverse expectations of stakeholders.
The accuracy of every estimation of working time depends on the following:
- Amount of data that the scrum team possesses
- To what extent is this data complete
- To what extent is this data valuable, useful, and crucial
- How stable this data is, how up-to-date it is, and how fast it changes over time
- Adopted reference story and points
- Ability to see analogies, differences, and relationships
- Experience in analyzing, estimating, and making predictions
- External and internal conditions which influence the course, tempo, and seamlessness of work
- Knowledge about crucial risks arising in agile projects
- Knowledge about variability and regularity of processes
- Whether the estimation will be conducted individually or collectively, and whether it will be done by specialists who will then perform the given work
- And last but not least, it will depend on adopted assumptions: it is crucial to accurately define the range, complexity, and relevance of taken actions.
The adopted metric by which you will try to express the work is also an important variable. Of course, the traditional metric is time (divided into months, weeks, days, or sometimes even hours).
With that said, you should be aware that the time expressed by a given unit, although it can seem objective, unbiased, and easily comparable, is not necessarily trouble-free as a tool for estimation.
Time as a unit in agile projects doesn't allow you to:
- Take into account the work done outside of the project (such as meetings, talks, and correspondence) that often overlap in terms of time
- Consider the specific work of a given team
- Focus on more significant and vital successes than the deadline (e.g., solving a technical issue of cardinal, strategic, or business importance).
Suppose you even once participated in the process of estimating the working time of the elements of the Product Backlog. In that case, you know that various developers will evaluate the same task (e.g., User Story) extremely differently.
This is because the subjective sense of time makes an hour mean something different to each specialist.
Of course, objectively, it's still 60 minutes and 3600 seconds, but how much work you can do in those 60 minutes and 3600 seconds is problematic, to say the least.
Various estimations have their sources in different experiences and competencies.
However, they also result from purely human issues such as habits, predispositions, motivations, preferred values, or, in more general terms, the preferred work culture.
So, if ambiguity is unavoidable, how can you accurately estimate and determine how much time a given task should take or how much effort it will require?
Absolute estimation methods (such as time) aren't always the most effective, whereas relative methods work well.
They are based not on defining the beginning or end of work but on indicating similarities between similar tasks in terms of selected criteria.
Comparing and estimating, which we wrote more about in the abovementioned article, is natural for humans.
We can see analogies and make predictions based on them.
And we have to admit; we are pretty good at it. This ability, innate and developed during species and individual development, allows us to obtain accurate estimations.
Story points are a technique that comes from the natural predispositions of humans. It allows us to estimate when to expect results and does so not with specific time measures but with story points.
It doesn't determine the date but the speed at which the Product Backlog will be completed. That said, we must strongly emphasize that Story Points cannot be boiled down to time.
Story Points measure speed, not execution time.
Story Points in Scrum — What are they?
Story Points in Agile/Scrum are understood as units of measurement used to estimate the effort needed to finish a User Story which can be, for example, a new functionality or an update of already implemented functionality.
Story Points are defined in terms of the:
- Complexity of a task
- Amount of work
- Work uncertainty.
Story Points are used during Sprint Planning and/or Grooming.
In other words, based on what User Stories are in Agile and Scrum, Story Points are a type of metric.
They help you determine how easy/difficult it will be to implement a given User Story, or in other words, how many story points it will take.
Thanks to the numerical value, which, as we emphasized, is not a representation of time, they allow you to determine the difficulty level.
Story Points are abstract measures, but they are helpful at the same time. A User Story with 3 points is twice as easy to complete than a Story with 6 points.
As you can see, Story Points determine the effort, speed, and distance that separates one task from the other.
Although they will not answer the question: When to expect the end of optimization? They will allow you to look at the process, work, and effects more multi-dimensionally.
Story Points are measures that take into account the complexity of a task, the effort that needs to be put into it, and the risk accompanying it.
Thus, they are much more comprehensive than time, which indicates and operates with only one value.
Story Point estimation refers to the following:
- Risk because agile projects always involve a large variability of requirements and conditions, and that's why they are problematic in estimating.
- Complexity, its consequences, and conditions are known from theory and practice; that said, it's not about complexity in a technological sense but purely programming sense and also the complexity of managing the project.
- Experience and repetitiveness of tasks (e.g., of implemented functions), which simultaneously gives an idea of their problematic nature, simplicity but also tediousness (e.g., it's necessary to take into account the effect of monotony, which makes work seem simple but it can be performed for a long time because of this effect).
Story Points can answer the following questions:
- Will you be able to carry out the Sprint effectively?
- Does the team have all the necessary information to conduct it successfully?
- Was the User Story optimally divided?
We should add that the final result consists of random factors and determinants (unexpected events in the form of malfunctions, work absences, and changes of members of the scrum team).
In summary:
Story Points are a metric used in agile project management and programming to estimate the difficulty of implementing a given User Story.
It is a number that informs the team about the difficulty level of the User Story. This difficulty is understood multi-dimensionally as a trait referring to complexity, risk, and effort.
The Story Point estimate is a type of relative estimation often performed during Sprint Planning and/or Grooming of Product Backlog.
Why should agile teams use Story Points?
First of all, the use of this technique is mutually beneficial. It provides real value to scrum teams as well as product owners.
Story Points allow scrum teams to:
- More precisely understand the range of expectations
- Accurately plan and effectively implement
- Develop a steady, optimal pace of implementation that guarantees satisfactory project progress
- Estimate without working under time pressure.
In turn, Scrum Points allow product owners to:
- Get a satisfactory return on investment
- Obtain a satisfactory quality-to-price ratio
- Better understand the specifics of digital product creation, conditions, and determinants
- More accurately predict long-term implementation of functionalities and updates of the digital product.
Even more importantly, Story Points help make product owners aware that referring to a single measure, while clear and conclusive, is often misleading and distorts the view of the situation.
Thus, it can create decision-making situations that consider a single variable whose weight is not always the heaviest and whose role is not always a priority.
Story Points measure the whole picture and its most essential components: risk, complexity, and uncertainty, thus enabling more effective Sprint planning.
Story Points are also "sensitive" to the differences between the various members of the scrum team and the particularities of each development team member.
Furthermore, Story Points strengthen teams, support teamwork, lift the often ineffective time pressure, and thus increase the productivity of scrum teams.
How to calculate Story Points?
When calculating Story Points, engaging all team members in this process is important.
From developers and testers to specialists responsible for deployment.
The essence of Story Points is the global perspective that allows you to see and estimate the total effort required to implement a given functionality.
That's why during the calculation of Story Points, it is essential to determine the following:
- Complexity of work
- Amount of work
- Technological capabilities and competencies of the team
- Risks and areas of uncertainty
- Tools and conditions that enable the work to begin
- Possible issues and critical problems
- Knowledge about the implementation of a given function and related problems and risks.
Story Points are often assigned during specifically designated meetings using the team's preferred techniques.
A typical meeting where estimates are made includes:
- Discussion about a given element from the Product Backlog
- Establishing an estimation matrix that takes into account risks, repetitions, and complexities
- Showing estimates done by team members
- Discussion of extreme values that are negotiated with the ultimate goal of reaching a consensus.
Story Points, often abstract values, can be expressed using various techniques and scales.
So how to determine story point value?
The most commonly used techniques to determine the value of Story Points include:
- Fibonacci Sequence
- Classical linear sequence: 1, 2, 3, 4...
- Planning poker.
When calculating Story Points, you should remember that they are relative. The numerical value represents the difficulty.
The value of one story point represents the easiest task, regardless of the type of project or character of the User Story.
Double base value — two story points — represents the double difficulty of a task and indicates that twice as much effort is needed to complete it. The triple base value — three story points — represents the threefold difficulty of a task.
The accuracy of the estimates largely depends on experience in the implementation of the given function and experience in the estimation itself.
For example, creating a contact page with contact form fields containing three fields and a second page, analogous, only differing in the number of contact fields, and requiring nine fields is not three times as complex and work-intensive.
Nor is it significantly different in terms of complexity. It is not three times as complex or three times as risky.
The difference is not fundamental but only relates to a narrow scope.
Obviously, if you assign a value of 2 Story Points to the first page, you will not give a value of 6 Story Points to the second page because such a difference between the two would simply be unrealistic. Or, to be more precise, inadequate.
When estimating Story Points, always remember that the common denominator for the summed amount of work, risk, complexity, and uncertainty is effort.
The effort associated with the work needed to be done, counteracting risk, overcoming complexity, and reducing uncertainty is the clue of the Story Points technique in Agile/Scrum.
What are Scrum Story Points? Summary
- The estimation of work required in Scrum User Story is quite troublesome.
- The ability to make the most accurate, close-to-truth estimation of working time is essential to the project's success.
- While it may appear objective, unbiased, and easily comparable, time is not necessarily unproblematic as a tool for estimation.
- Absolute estimation methods (e.g., time) are not always the most effective.
- Story Points in Agile/Scrum determine the effort, speed, and distance that separates one task from the other.
- Story Points are measures that also consider a task's complexity and the risks accompanying it.
- Story Points help make product owners aware that referring to a single measure, while clear and conclusive, is often misleading and distorts the view of the situation.
- Creating Story Points is a team effort.
- Story Points are also "sensitive" to the differences between the various members of the scrum team and the particularities of each development team member.
- Most often, the Fibonacci Sequence, planning poker, and a classic linear sequence: 1, 2, 3, 4, are used to determine the value of Story Points.
