Story points are an abstract unit of measure used in Agile project management and development to estimate the complexity of implementing one or more user stories, and are a way of describing the effort involved. A story point is a number that tells the team the complexity of the user story. Complexity includes the ease of functionality, risk, and effort.

Unlike estimated time, a story point is a relative estimate that cannot be equated with units such as “person/day” because the time required for each person to perform a task of the same complexity varies. Let’s take an example:

Suppose team T has three employees, A, B and C. The ability of Mr. A is twice that of Mr. B, and that of Mr. B is twice that of Mr. C (the ability cannot be compared in this way, but it is only convenient to explain the problem here). Team T has agreed on an iteration of 10 days, and now they want to plan their future work. If, according to the estimated time, user B thinks A story needs 1 day, user A thinks 0.5 days is ok, and user C thinks 2 days, how much will they decide?

There are two possible outcomes:

The first result, A said this I will do, write 0.5 days! If we follow this approach, then the whole planning meeting will evolve into A division of labor meeting. When A picks A number of user stories and does the estimation himself, so does B and C. When everyone’s total estimation approaches 10 days, then the goal of the iteration will be determined. This is what many teams actually do, and it may seem like a good idea, but over time, the downside of this approach becomes apparent.

  1. Do your own thing and don’t care about the whole situation. Since everyone’s own work content has been determined, it is ok for everyone to arrange their own work, why care about the work of others?

  2. Poor risk resistance. If Mr. A takes A day off, it takes Mr. C 4 days to make up for it. It not only had a huge impact on Mr. C’s plan, but also made the whole team’s estimate far different from the reality.

  3. Not seeing the true speed of the team. Whenever PO asks if some user story can be scheduled for the next iteration, the answer is usually “it depends on who is available”.

  4. Bad for the growth of team members. It is difficult for Mr. C to have the opportunity to do some complicated work that can improve his ability, because due to the consideration of time cost, the complicated work is entrusted to Mr. A.

There’s a second possibility, of course, where you decide to pick a middle number, but what’s a reasonable middle number? More estimated time means less work gets done overall, and less estimated time means more chances of not getting done.

Instead of estimating time, story points focus on complexity, allowing everyone to have the same perception of complexity for the same user story. To do this, the T team can find a baseline user story (hereinafter referred to as the baseline story), not necessarily the smallest, but one that resonates with everyone on the T team. The T team then defines the first baseline story as one story point.

When estimating a new user story X, everyone needs to think, does story X take more time than the base story? If story X is twice as complex as the base story, then clearly story X should have story points of 2. Note that the story points follow the Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34…) “, but in practice, many teams replace 21 with 20,34 with 40, and so on, for easy memorization. Here is my Scrum playing card.

These cards mean:

  1. 0 means it takes just a sip of water.

  2. Other numbers are based on comparisons with the benchmark story.

  3. ? Presentation complexity is unknown, and user stories often need to be discussed or split.

  4. Coffee means you’ve overestimated, you’re tired, and you need a break.

In principle, a good agile team should not estimate user stories of more than 8 story points, and stories of more than 8 story points should be broken down into smaller user stories. Over time, the T team will have more and more base stories that correspond to story points 1, 2, or 3. This makes everyone’s estimation of new user stories more accurate.

Of course, in the real world, even if everyone knows what one story point means, there will still be a debate about whether a user story should have two or five story points because of the difference between each person’s situation. Some people consider more, some people consider less, some know some shortcut, some people a blank face. The correct procedure is this:

  1. Instead of telling your story point, each of you should put the corresponding paper plate on the table.

  2. When everyone’s cards are buckled on the table, everyone turns over their cards together.

  3. Please discuss the reasons for the two members with the largest difference in estimates.

  4. Everyone take back the cards and repeat steps 1-4. Until everyone’s estimates agree.

The benefit of using this approach is obvious, it allows everyone to agree on a story point, which means that whoever is writing the user story is endorsing the story point. And it’s a great way to avoid unthinking copycat behavior — everyone has to think about the complexity of the user story to come up with a relatively reliable story point, or explain it to everyone else.

The downside to this approach is that planning meetings can be time-consuming. In practice, some teams put the estimation session before the planning meeting, while others went straight to a relatively correct story point through full discussion without poker.

The T team’s estimation of user stories requires constant refinement, as well as team speed. Mr. A, Mr. B, and Mr. C have already completed estimates for several user stories in the planning meeting, with A total of about 40 story points. Can team T complete those 40 story points? Practice is the only way to test a guess.

After a few iterations, the T team found that 30 story points was just right, neither tight nor slow, so the T team’s team speed was 30 story points per 10 days.

One of the benefits of team speed is that if team T plans A total of 30 story points of user stories in an iteration, team T can theoretically complete all of these stories on time regardless of who is doing each story. Of course, the speed of T team is not constant. The following figure shows the speed of my team in the last three iterations.

(Screenshot from Worktile development)

It is very scientific to scale the work of the next iteration based on the team’s pace over time.

The T team had a clear understanding of their team’s capabilities and was confident in the goals of the iteration. In addition, the T team can insert a certain percentage of non-functional requirements into the iteration, depending on their team speed.

In addition to team speed, story points can also be used to visually reflect the progress of T team in an iteration. Below is the burnout chart of Sprint 10 for which I am a member.

(Screenshot from Worktile Agile)

The trend of burnout chart can effectively reflect whether the T team is out of control at present. If the burnout chart is always high, everyone needs to discuss in the stand-up meeting and jointly find, take responsibility for and solve problems, which can be called a team, right?


Author: Worktile Sun Jingyun

Worktile’s website: Worktile.com

This article is from Worktile’s official blog.