Story Point Estimates Are Best Thought of as Ranges

When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number.

One of the questions I often get about story points is what to do if you can’t decide whether a particular product backlog item should be an 8 or a 13 (or a 3 and a 5). Part of the answer can be found by thinking about water buckets.

Suppose you have 10 liters of water you need to store. You also have an 8-liter bucket and a 13-liter bucket.

Which bucket would you store the water in?

The 13-liter bucket, right? Ten liters of water doesn’t fit in an 8-liter bucket. The water would overflow and spill out.

Extrapolating further, you’d use the 13-liter bucket for all amounts of water from 9 liters through 13 liters. Once you hit 14 liters, though, you’d once again need a bigger bucket.

And so it is with the values you choose to use when estimating stories. Think of each value as a bucket. A value bucket is used for all stories between that value and the next lower value.

Read the complet blogpost here:

How to Work with Complex User Stories That Cannot Be Split

Most user stories can be split. It may be hard to find a good way to split some stories, but most can be split. These are known as compound stories—stories that are made up of multiple smaller stories.

There is another type of story: the complex story. Complex stories are ones that cannot be split. They are inherently large or complex and there are no subparts to be pulled into separate stories.

Even with a complex story, you don’t want to let the story linger open for three, four or more sprints. Doing so

  • Makes velocity less predictable from sprint to sprint
  • Increases the risk of a developer going astray from user expectations , and
  • Allows the team to develop the bad habit of leaving work incomplete at the end of an iteration

Use Progress Points to Identify Accomplishments

Read about it in this article:

How to Deal with Bad Scrum User Stories as a ScrumMaster

It is common in the early stages of Scrum implementation for there to be misunderstandings about what User Stories are for and what makes them useful. A ScrumMaster’s task is to be able to help the Team and Product Owner when they are faced with ineffective User Stories as they go into Sprint Planning.

Read the complete article here: