How to Estimate User Stories by Relative Scale?

2022-06-24 10:20:57
ZenTao ALM
Original 828
Summary : An agile team can avoid prolonged and unpredictable planning cycles through precise iterations and WIP on the Kanban board. While these agile practices are more flexible and adaptable, the importance of user story estimation in the delivery process cannot be ignored, as it is the only way to communicate work delivery times with leadership.

How to Estimate User Stories by Relative Scale?

In fact, without a good system or tool, it's hard for us to estimate user stories and often even overestimate or underestimate the work we have to do. And for traditional companies that need to spend weeks or months developing long-term plans, the result is bound to deviate from the initial estimates once interruptions occur.


An agile team can avoid prolonged and unpredictable planning cycles through precise iterations and WIP on the Kanban board. While these agile practices are more flexible and adaptable, the importance of user story estimation in the delivery process cannot be ignored, as it is the only way to communicate work delivery times with leadership.


Over time, estimation helps us understand the speed of our teams so we can predict work more accurately. And by introducing relative scale, we can estimate better and faster.

1. What Do We Have to Estimate?

The Agile team estimates each user story and writes it on a user story card.


A user story is a short description of the functionality required by the customer, and a user story card is a card that shows a certain delivery unit for the agile team based on the user story. Agile teams have to estimate the scale of each story.

Source: user story

We need a more direct way to evaluate user stories to ensure we don't spend a lot of time planning only to switch back to a waterfall approach because we couldn't fit the plan in.


If teams start doing user story estimation, they generally think in terms of hours. But this doesn't work because we're usually less accurate in predicting time. This is one of the reasons why we prefer short iteration cycles over marathon planning.


How do we estimate user stories if the story scale cannot be linked to hours? Here it is recommended to use a relative scale for estimation.

2. What is the Relative Scale?

Let's look at the two components of the term: scale and relative.


First, the size of the story needs to be estimated, which consists of three factors:

  • Effort: How much work is required to complete this task?
  • Complexity: How difficult or complex is this task?
  • Uncertainty: Do we know clearly what to do to complete the job, or do we need to learn while doing the job?

The scale of the story is the size of the story considered by combining these three factors.


Second, the size of the story is relative to the rest of the team's user stories.


That is, we can determine which user story is bigger or smaller by comparing multiple user stories rather than planning the size for the stories individually without reference.

3. Fruit Salad Game

For newcomers to relative scale estimation, we can introduce this concept with a simple game.


Now there is a demand that we should bring a fruit salad to the party. We have several kinds of fruits in our hands: an apple, a bunch of grapes, a pineapple, etc. We need to prepare every fruit, including washing, stoning, cutting, peeling, etc.


Then we can only get one fruit at a time and need to estimate the size of the task of processing this fruit, where the estimation considers the workload, complexity, and uncertainty of processing this fruit.


First, we start by marking all scales.

Source: user story

Then we'll handle the apples. Since it will take a few minutes to the core and dice the apples, we can start by labelling the apples as medium size. This task is not very complicated.

Source: user story

Next, you need to process the grapes. It may be easier to clean the grapes than the apples, which only need to be cleaned and the roots removed.

Source: user story

Then it would be best if you handled cherries, watermelons, pineapples, etc., and determine the size of these tasks.

Source: user story

After you have a general standard for all fruit tasks, you can share your opinions among the team. For example, a team member thinks that the task of dealing with grapes should be more complex than the task of dealing with cherries because grapes need to be picked and cleaned and seeded individually. But another team member thinks that grapes need not be implanted; therefore, the task is more accessible.


After these different views are put forward, the team must clarify a standard for making salad: Do grapes need to be seeded? Do apples need to be peeled? After unifying the standards, everyone aligns on the task to achieve an estimate.


In an actual project, we can apply the thinking of making a salad, such as which user story can be positioned as a medium-sized user story and setting a standard user story size based on this. At the same time, compare other user stories with that story to determine the extent of other user stories. After understanding how to estimate user stories by relative scale, try this method in your actual team.

Write a Comment
Comment will be posted after it is reviewed.