Last updated on 9/9/24

## Discover Story Points and Other Units of Measure

In this chapter, we will look at some of the units of measurement that are popular for teams using relative estimation, including:

1. Ideal time

2. Story points

3. T-shirt sizing

4. NUTs

These units of measurement are often used with user stories.

One of the common fallacies with breaking down features into tasks and estimating how long each task will take is that this approach makes a lot of assumptions.

One of the main assumptions is that since the tech team works 40 hours a week, you can assign 40 hours of development tasks to each of them.

However, consider some things that could happen in the typical day of a developer:

• She attends meetings.

• A fellow developer asks her for help.

• She takes a lunch break.

• She takes some toilet breaks.

• A weird bug on the live production site needs some researching.

In a previous section, we estimated how long it would take to read a book by first estimating size and then how long it would take to read. Ideal time allows you to do just that.

Estimating something using ideal days would require another calculation altogether to determine actual calendar days required to release a feature by a certain date.

One major benefit of ideal time or ideal days is that it is very easy to understand. If you explain to a business stakeholder that developers work for four hours on coding per day and four hours on planning, meetings, lunch, toilet, answering questions and so on, they can better understand the estmates.

If using the Agile project management framework called Scrum, estimation will be done in story points. Story points are units that are given to each feature during an estimation session - the available set of numbers are inspired by the Fibonacci sequence.

Story points usually simplify the Fibonacci sequence by going up as far as 21 and then including the number 100 as the biggest number. Although 100 is not a number in the Fibonacci sequence, it is a very big number in this context and is interpreted to mean  that the feature is too big to estimate and should be broken down. Story points tells you the complexity of the feature (how big it is) but not how long it will take to complete.

Let’s take a look at a couple of examples:

Imagine a Scrum team working on a new e-commerce application. During a sprint planning meeting, they have the following user stories:

• User Story A: As a user, I want to be able to create an account so that I can make purchases. (Estimated at 5 story points)

• User Story B: As a user, I want to be able to search for products by name. (Estimated at 3 story points)

• User Story C: As a user, I want to be able to add items to my shopping cart. (Estimated at 8 story points)

These estimations are based on factors like the complexity of the tasks, the amount of work needed, and the team's understanding of the requirements.

If the team can accomplish around 16 story points per sprint, they might decide to include User Stories A and B in the next sprint, as their total is 8 story points, leaving room for additional work or for addressing unforeseen challenges. User Story C might be planned for a subsequent sprint, as including it would exceed the typical amount of points they can do in each sprint.

By using story points, the team can make more informed decisions about what they can achieve in a sprint and manage their workload more effectively.

Here’s another example. The first line consists of changing one line of code, while the last line involves migrating an entire database (represents hours of work and hundreds of lines of code):

This difference is not a multiplication of complexity by 13, but a relative complexity between two user-stories. Migrating a database represents much more work than the user story that consists of modifying a single line of code.

Estimating by story points is the preferred way of estimating for most Scrum teams. It offers several advantages, such as:

Relative Estimation: Story points allow for relative rather than absolute estimation. This means teams estimate the size of a task compared to other tasks, not in absolute time units like hours or days. This approach is generally more accurate since humans are better at comparing things than at predicting absolute values.

Focus on Complexity and Effort: By using story points, teams consider various factors like complexity, unknowns, and effort required. This holistic view often leads to more realistic estimations compared to just considering the time it might take.

Team Consensus and Collaboration: The process of assigning story points typically involves the whole team. This encourages discussion and consensus, leading to a better understanding of the task and a more cohesive team effort.

T-shirt sizing is where you attribute one of the following t-shirt sizes to each feature:

• S - Small

• M- Medium

• L - Large

• XL - Extra large

• XXL - Extra extra large

One great thing about T-shirt sizing is that it is very easy to understand. Almost anybody can tell you whether they think something is small, medium or large. (In fact, it may remind you of the coffee cup example earlier in the course.)

Identifying a feature as medium doesn't tell you how many days it will take to complete. This will be looked at in a separate exercise that will use user-story and story-point breakdowns instead.

NUT is an abbreviation for Nebulous Units of Time!

It is another label for a unit of relative measurement.

NUT is considered a little flamboyant and places the emphasis on the arbitrary and "made-up" nature of this unit of time. It is clearly an artificial unit and not real time.

• When using relative estimation, estimate in units other than days.

• Popular units of measurement for relative estimation are:

• Ideal time

• Story points

• T-shirt sizing

• NUTs

• If using an Agile project management framework called Scrum, estimation will done in story points.