Story Points Properly Done

  • Consistent Task Size
  • Consistent Code Delivery
  • Consistent Quality
  • Lets you break tasks down into consistent units of work.

What is the difference between Agile and Scrum?

These terms are frequently used interchangeably or in the same sentence: "We are agile because we do scrum." In a nutshell, Scrum is a framework of processes to achieve an Agile workplace.

Agile is a philosophy

The Agile Manifesto was published in 2001 by a group of 17 developers. Many are legends in computer science and speak and write about code.

https://agilemanifesto.org/ and also https://agilemanifesto.org/principles.html.

I encourage you to read about it from the original source.

What you may notice from the source is there is no mention of scrum, standups, scrum masters, events, or artifacts. These are part of Scrum.

Scrum is a process framework

Scrum was created by Jeff Sutherland and Ken Schwaber in the 1990s. They were both also creators of the Agile Manifesto.

https://www.scrumguides.org/scrum-guide.html

You should notice that Scrum predates the agile manifesto by about 6 years.

What are Story Points?

Story points are a measure of relative effort for a task. So if it will take you the same amount of time to vacuum the house or wash the dishes they may both have a story point value of 2, but cleaning the garage would take 4 times as long so that would have a value of 8.

Story points are not mentioned in either the Agile Manifesto or Scrum Guides. Mike Cohn is a tremendous proponent of story points:

https://www.mountaingoatsoftware.com/

He has created a number of books and video courses about agile and scrum.

According to his blog, story points represent the effort to develop a story.

Story points are a measure of effort. The amount of effort is shown by relative values: A 2 point story should take twice as much work as a one point story, and a 5 point story should take 5 times as long.

Stories ultimately get converted to hours. There is some spirited discussion on Mike Cohn's blog post on the main benefit of story points. Mike Cohn's position is that a task has a story point value. One developer may finish it in 5 hours, and another may take 15, but it is still a (3) point story.

On my teams this has led to confusion. In my experience, since you bill or track hours, at some point you are converting points directly to hours. We just say that for me, this is a 3 point story but for you it may be an 8 point story. Each point represents 6 hours of work.

The difference between story points and hours

Why don't we just use "hours"?

Everything goes against hours. You get paid for hours. Clients get billed for hours. Assigning story points to hours is a practical solution.

Hours are measured and paid, story points are measurements of work.

How to calculate story points

Some teams play planning poker. Most teams utilize some variation on the Fibonacci sequence. Story points calculation using Fibonacci Sequence makes developers sound smarter than they are, so that is what is usually used.

A Fibonacci Sequence is created where the next number in the sequence is the sum of the 2 previous ones:

0,1,1,2,3,5,8,13,21...

so:

  • 3 = 2 + 1
  • 5 = 2 + 3
  • 21 = 13 + 8, etc.

As numbers get larger the distance between each level of difficulty grows. This indicates a level of certainty and a level of complexity.

Low effort task: 1-2 points

Medium: 3-5 points

Large 8-13 points

Beyond Large (21) should be broken down into smaller units of work.

Benefits of using a Fibonacci sequence when assigning story points

By forcing story points to be part of a Fibonacci sequence, larger tasks will be buffered with more uncertainty.

When the level of difficulty is too great, break the task into smaller ones. Smaller tasks reduce the number of unknowns and allows for more precise estimation of time.

You should also include estimates for planning/discovery and QA effort in the point value of a given task.

Breaking down tasks allows for better estimation

Most programmers underestimate terribly. We think that we can rewrite our company's code base in "3-6 months."

By breaking down tasks and assigning a value to each task you can get an idea of how long something will actually take by summing up all the details as you go along.

Example with Epic and Tasks

Epic:

Connect to a payment API (Developer's first guess: 3 days)

Tasks with points assigned:

Task Planning Points Dev Points QA Points Total Points (All total values in the Fibonacci sequence) Create Git Branch & configure dev environment 0 2 0 2 Create data schema to store the token 2 2 2 2+2+2 = 6 Round up to 8 Get a Token from the API 2 3 3 2+3+3 = 8 Parse the results 1 3 3 1+3+3 = 7 round to 8 Log the results 1 3 2 1+3+2 = 6 round to 8 Total effort: 6 13 10 34 (This happens to be Fibonacci)

Depending on the division of work, if a story point is a half day of work it will take at least 8 work days with a developer and QA working at the same time.

Analyzing Story Points

The wrong way


Micromanagement. "Why was your velocity off this week?" "Work overtime to get in the extra points!"

Story points should really be private to the scrum team as a way to monitor internal progress. What you ultimately deliver to the business can be measured and discussed but story points are "how the sausage gets made" by the development team.

The right way

Assigning story points to tasks and working with that system over time allows developers to learn how to estimate your tasks better. Story points let you see how far off you are and refine your estimates of new tasks over time.

Getting better at estimation:


Developer thinks they can do 10 story points in a week, but actually do 5. They thought that a task was medium: it turned out to be hard. Why?

Over time you will figure out how much work you can reasonably get done in a certain amount of time.

You will also learn how time consuming or difficult certain tasks are. If there is one task that takes you a week, it was not sized correctly! Certainly on reflection you will realize that your task was actually more than one task. In the future, you can account for each task and break it down further. Underestimating the size of a task will train you to identify and scope the sub-tasks.

Let us know what you think in the comments!

Video