Are you putting too much Effort into Story Points?

Avoiding the traps that lead to individual estimates

Many practices we see in organizations are so common people often think that they are as much a part of Scrum as the Sprint Retrospective or the Scrum Master role. One of these standard practices is the use of Story Points. Estimates in Story Points can be a valuable tool to help plan what goes into a Sprint. However, there are a few places where teams tend to get tripped up when trying to understand Story Points and how to use them. Two issues often seen are what a team considers during their Story Points conversations and who creates the estimate.

To start, let’s define the idea of Story Points. Why do we want to measure what the team is about to do in some made-up numbering scale instead of just measuring in hours?

The problem with measuring software development work in hours is that we are constantly working to build something new and unique. Every day a developer works on an application, it may be something similar to what they have done before, but it isn’t the same thing repeated from earlier. Thinking and solving unique problems every day is the core of knowledge work. This type of work is vastly different from jobs filled with daily repetition or where the specific steps to accomplish the task are known when you start.

So instead of using time when we are estimating a User Story, many teams use Story Points.

What goes into a Story Point

I think of a Story Point as having 3 parts:

Complexity + Unknowns + Effort/Work

The first question to think about when estimating in Story Points is complexity. The number of components and connections in the area of code to be changed increases its complexity. Think about if this is an isolated method or are you working on a densely connected system? If changes are being made to a complex system, the Story Points estimate should be higher to account for that.

Next, you will want to consider unknowns. Some questions to ask while estimating a User Story could be — is the area of the code well known, or will this be changes to a legacy system? Has the team worked on a problem like this before, or will this be something new? When estimating, we want to think about unknowns because this is a vital part of doing knowledge work — solving a problem where you don’t know all of the answers when you start.

Now on to the third thing where many teams get themselves tripped up. There are two options for words to use here, and I’ll show why I prefer one over the other.

Effort vs. Work

Most of the time, teams will talk about the Effort to complete the User Story. They think in terms of the labor that will be needed to complete the story. Some stories will be easy and require little Effort, while others are much larger and need considerable Effort to get done.

Here is the catch — When we say the word effort, we get anchored to the idea of the force people are putting into completing the item. This word inadvertently causes us to think about the ability of who might be working on the User Story. Something that could take a lot of Effort for a Junior Developer to complete might be straightforward for a Senior Developer to knock out. This can lead a team toward the anti-pattern of wanting different estimates depending on who would work the User Story.

So, instead of using the term Effort, use Work. We want to think about the tasks — the Work needed to get that item Done. While individual skill and experience can impact the amount of Effort or labor spent, the Work accomplished is the same — You have a piece of working software.

Dictionary.com definitions of these terms show this same idea.
Effort — “Exertion of physical or mental power.”
Work — “Exertion or effort directed to produce or accomplish something.”

Considering Work in the Story Points instead of Effort keeps us focused on the result we are trying to achieve. We want to think about the tasks needed to complete the story.

To use another kind of example, let’s imagine I have a bathroom faucet that needs replacing. I can replace it myself or call a plumber to do it. The plumber is more experienced in this area, so the Effort would probably be low for him. But for me, I understand what I need to do, but I don’t have much experience. So I would have to put in more Effort when changing this faucet. However, regardless of who replaces the faucet, the Work result is the same — disconnecting the incoming water, removing the faucet from the sink, attaching the new faucet, and hooking up water again. So, if we focus on Work rather than Effort in our Story Point, that can help us not get different skill levels mixed up in the Estimate.

Team or Individual Estimate

Another place that Effort tends to show up instead of Work is with how a team determines the estimate for a User Story. Many teams have a practice called Planning Poker when assigning story points to work items. The idea is that everyone reveals their estimate simultaneously, then the team discusses to come to a group consensus.

I saw this estimating tool fall out of favor with several teams who were moving to remote work for the first time because of the Pandemic. As a result, they traded away the benefits of a team estimate to have quick estimates from one team member.

There are a few reasons we want teams to have a group consensus and not a single opinion making the call, and part of this goes back to if your team uses Effort or Work when creating an Estimate.

If a single person makes the call on the story points, you lose out on the conversation and understanding that discussing multiple points of view can give. Not only does this conversation help to uncover assumptions or different interpretations of the story, but it can also help move the Estimate toward the Work to be done and not just the Effort in doing it.

By getting several perspectives in the open to determine the team estimate, the conversation can focus on the Work to complete the item. This discussion will help build that shared understanding of what that story will require instead of only getting one person’s thoughts on what will be needed.

Conclusion

In practice, Story Points intend to be a lightweight and quick way of getting Work estimated by a team to help them with Sprint Planning. However, we have to watch when the team tries to optimize for quick estimates so much that they lose the benefits of having a common understanding. We want our teams to always think about a team estimate, not just considering how much effort it would be for them personally.

A key area to help them focus on that shared team estimate is keeping the Work in mind and not getting tripped up over the Effort it will take to do that Work.

First published in Serious Scrum on Medium.com

https://medium.com/serious-scrum/are-you-putting-too-much-effort-into-story-points-ff3d2cbc93e0