Tag: sprint

Using Story Points Correctly

TL;DR

Your sprints will be successful if you use points as relative work and if you base your sprints on your team’s average point completion rate. Otherwise, you will either not complete as much as you expect or you will complete stories faster than expected, setting you up for failure in future sprints.

Points are relative work

Points are used to compare stories against the smallest amount of work (e.g., changing CSS colors, fonts or some other simple thing). I wrote more about that previously in How Not To Use Story Points.

If a story is pointed at 3, asking the developer to “point it a 5” will not make the story result in higher quality, include more features or be done faster (or slower). The work drives the points not the other way around.

Pointing Stories

How stories are Pointed is just as important. It is easy for the developer to hem and haw and pull a number out of the air, but that leads to poor pointing. Instead we want to mix in some rubber ducking.

English: A rubber duck assisting with debuggin...
A rubber duck assisting with debugging code. (Wikipedia)

To do this, the developer needs to explain the story in enough detail so that someone not familiar with the work can understand the level of effort that it requires to complete the story.

For example, a story to add a log in screen to a page might be described like this:

  1. The screen has the following elements:
    • email and password fields
    • a “login” button
    • a “forgot password” link, and
    • a “signup” link
  2. Both fields are required and appropriate error messages will display if either are not filled out when the login button is pressed.
  3. If the credentials are incorrect, a notice will be displayed with the text “email and/or password incorrect”, the password field is blanked, but the email field retains whatever value was previously entered
  4. Clicking the forgot password link will go to the password recovery screen
  5. Clicking the signup link will go to the registration screen
  6. If the user successfully signs in, they will go to the dashboard screen

Voting

Once the story is adequately explained, then the developers must all vote on it. This serves as a “reality check” and prevents skewing by any one person. Whereas one person may see the work at one number, others may view it at another. The rough average of votes is taken (sometimes throwing out the high and low, depending upon the group) and fit in the point scale: if the team used the fibonacci scale and a vote average was, for example, 4, it would be pointed as a 5 to fit in the scale.

The most effective voting system is done where no one can see how the others voted until all the votes are cast. This prevents issues of groupthink.

The Sprint

Keeping track of the average number of points delivered in prior sprints is a good way of estimating the number of points one can expect the same team can deliver in the current sprint. Remember, the work drives the points, not the other way around, so insisting the team deliver Widgets 1 through 5, when the points say they should only be able to deliver 1 through 3, is the way to deliver even less.

Things that can affect delivery are team members’ absences (due to planned vacation or sickness), bugs and mispointing.

If a team member is absent, they obviously cannot deliver the points they normally could. If the absence is planned, then reducing the expected points for that sprint is one way to mitigate the risk.

Bugs should never be pointed, because they do not add value and cannot be sized against stories. Bugs are bugs, so time spent on bugs is expected to cut into time available for building features. This will naturally reduce the expected point delivery over time. The average point delivery will reflect bugs the team encounters.

Mispointing is less of a concern when there are enough (3-5) developers present to vote on each story. If the story is sufficiently described, and outliers are discarded, better accuracy can result.

How (not) to use Story Points

Abstract (tl;dr)

Story points should never be used to represent hours, but simply relative size of effort to complete a story. Over time, the team will tend to complete a consistent range of story points each sprint. Trying to tie story points to duration breaks the model and leads to inaccurate forecasting. Points should not be used to compare teams, nor should they be used to compare bugs.

Introduction

In Agile projects, each work packet is called a Story. Each story has a point value assigned to it.

I prefer to use the Fibonacci scale for story points.

1, 2, 3, 5, 8, 13

Each number is the sum of the previous two numbers (3 = 2 +1; 8 = 5 + 3; etc).

But what do these points mean? We will get to that in a minute, but first let’s examine how difficult it is to estimate sizes.

Glass of Water

English: Glass of water sitting on a coaster.
(Wikipedia)

How many ounces of water is in the glass? If you’re like most people, that is not an easy thing to guess.

On the other hand, if I compare it to the glass below, I might say is has roughly twice as much water, and I would be mostly correct.

en: A glass of water / de: Ein Glas Wasser / t...
(Wikipedia)

This is the concept of story points.

1 is the baseline amount of work.

2 is twice as much effort

3 is three times as much, and so on.

Either 8 or 13 are “too big to do”—otherwise known as EPICs—and are slated to being broken up into smaller stories later.

The reason this is done is because it is easier for humans to judge a relative size than an absolute size.

Smallest amount of work

The effort of the smallest amount of work is considered a “1”. For web projects, this is often the effort required to change some element’s CSS style (color, font, size, etc).

Every other story is compared to this task.

Count the points

During the course of the sprint, the team completes the stories. And the end of the sprint, all completed story points are summed and that is the number of points completed for that sprint. After 3-4 sprints are completed, the average number of completed points for the prior three sprints is a good indicator of the number of points the team will complete in the next sprint.

Sprint 1 Sprint 2 Sprint 3 Average
14 18 14 15 (rounded down)

As you can see, points cannot be hours because the number of points varies, based upon many factors:

  • Team members’ skills
  • Team leader’s leadership
  • Distractions/work environment
  • Complexity of work
  • Tools/equipment quality

Points are not fungible

fungible (fŭnˈjə-bəl)

adj. Interchangeable.

Points are not fungible, that is, they are tied to the team. One can’t judge one team’s performance against another’s by counting points, because of the factors that cause variability in points. One team might complete 15 points in a sprint, while another might complete 40. The first team is not worse than the second team; points mean different things for the two teams.

Bugs don’t Point

Donald Trump enters the Oscar De LA Renta Fash...
HUUUUUGE! ( Wikipedia)

You can’t point bugs. Well, you can, but you’re making a huge (huuuuuge) mistake. When pointing stories, one needs to explicitly lay out the tasks required to complete the work. Then, that work is compared to the Smallest Amount of Work and given a point.

Bug HAVE NO defined tasks required to complete the work because no one knows what is causing the bug. What are the exact steps required to fix it? There aren’t any; one simply works the problem until it is fixed.

For example, let’s take the “bug” of me losing my car keys. How late will I be? If I estimate the tasks to find my keys, it will be something like:

I will look:

  1. In my backpack
  2. On the table
  3. In my pants
  4. On the kitchen counter
  5. On the bathroom counter
  6. On the nightstand next to my bed
  7. Under the nightstand next to my bed

Given all that, when will I find my keys? After #1? After #8? Later?