A major goal of backlog grooming is to provide effort estimations for backlog items that are either not estimated (usually because they are new) or improperly estimated (usually because they were previously estimated and the team feels that the estimate is wrong). It is extremely important to keep the Product Backlog properly estimated at all times, as this helps the Product Owners and Project Leads keep the project on track and accomplishing the project’s stated goals.

Because the Product Backlog is constantly changing, the responsibility for keeping the Product Backlog estimated is a difficult job. New items are created from new requests or from slicing existing items on a fairly continuous basis. As a result, we need an estimation technique that is both reasonably accurate and easy to do. “Story Points” give us a way to achieve both reasonable accuracy and ease-of-use.

The responsibility for estimating the Product Backlog falls completely on the Scrum teams (in Agile Development, estimation is ALWAYS done by the people most likely to build the item and is ALWAYS done as a group activity). Backlog Grooming sessions give Scrum teams an opportunity to fulfill that responsibility.

Steps to Estimating a Backlog Item

To estimate backlog items during Backlog Refinement, the Product Owner should come prepared to discuss all backlog items that are not estimated as well as the highest-priority backlog items that will likely be discussed by the team during the meeting. The estimation process itself is fairly simple (once you have the basic understanding). To estimate a backlog item, follow these steps:

1. Discuss the backlog item until everyone who is estimating understands the item.
2. Compare the backlog item to previously estimated backlog items and ask
3. How complicated is this item? How simple is this item?
4. Have we done items like this in the past?
5. Do we have the skills we need on the team to build this item?
6. Is this something that requires lots of repetition?
7. Reveal your estimate to the rest of the team.
8. Discuss your estimate with the rest of the team and, based on that discussion, decide if you want to change your estimate.
9. Come to an agreement across the team on the estimate.

Problematic Methods to Avoid

As was mentioned in a previous post, Backlog Refinement is all about functional slicing of backlog items, not determining a solution. Similarly, we estimate story points by looking at the complexity of the item, not how we plan to build or solve the item. Therefore, every backlog item MUST be looked at in terms of whether or not it’s bigger or smaller than previous estimated items. If you attempt to estimate each item on its own merit, you’ll essentially be creating a new story point scale for each backlog item that you estimate. What this means is that the following methods of estimation will cause significant problems over a long period of time and, at the very least, will likely result in more costly and less effective estimation techniques.

• Relating story points to hours, days, or weeks. This is essentially the same as not using story points. First, each estimator has to figure out a probable solution. Then they have to figure out how much time their solution would take. Then they have to resolve their solution and estimate with everyone else’s solution and estimate. In the end, this method is no better than doing estimates in hours. It is no more accurate than story points, but it costs a lot more to do.
• Relating story points to things like “easy”, “very easy”, and so on. If not used carefully, this forces each estimator to come up with their own definition of “easy” and then to apply that mental standard to each backlog item independently.

Sample Backlog Items & Examples

For story point estimation to work properly, we want to look at backlog items relative to one another. For example, let’s take a short list of sample backlog items.

• STORY 100: I’d like a new front door that is more energy efficient.
• STORY 101: I’d like the small bedroom re-painted a new color.
• STORY 102: I’d like the flower beds in the front of the house to be replanted.
• STORY 103: I’d like the kitchen remodeled so that there’s more space.
• STORY 104: The mailbox needs to be replaced.
• STORY 105: The house needs roof repairs.
• STORY 106: I’d like a faster wireless router installed.
• STORY 107: Replace the microwave oven.

We also have the following backlog items previously estimated. Most are completed, but a few are scheduled for the next iteration. Here they are (and don’t argue with me, they’re just an example):

1 Story point

• Clean the bathroom
• Do the dishes
• Cut the grass

2 Story points

• Do the laundry (wash and dry clothing)
• Pick up the leaves in the garden
• Pull the weeds from the flower beds
• Fix the water leak in the kitchen sink
• Clean the windows (inside and outside)

3 Story points

• Switch winter clothing for summer clothing
• Clean the fireplace

5 Story points

• Repair the gate in front of the house

8 Story points

• Patch cracks between bricks on the outside walls of the house

To estimate the not-estimated backlog items, we simply discuss them with the Product Owner (for me, that’s my wife) and, having reaching a clear understanding of the backlog item and having asked questions like “how hard does it appear to be?”, “have I ever done something like this before?”, and “is this a repetitive job?” I get to work estimating.

We’ll start, not surprisingly with STORY 100 (“I’d like a new front door that is more energy efficient”) In my discussion with my wife, I learn that she wants the same color and style we currently have, she just wants one that doesn’t feel like its open even when its closed. And, lucky me, I’ve done this type of job before, so I’m familiar with it. To me, it’s definitely harder than “Clean the bathroom” (1SP) and “Do the laundry” (2SP). It’s a little harder than “Clean the fireplace” (3SP), but probably not quite as hard as “Repair the gate in front of the house” (5SP). So, given either the 3SP option or the 5SP option, I’ll go with 5 story points because I know it’s harder than cleaning the fireplace and, if there’s a problem getting the old door out, it could definitely be similar to repairing the gate in terms of complexity. So, STORY 100 gets a 5SP estimate. Next!

STORY 101 is just repainting the smallest of the three bedrooms in the house. No problem. I’ve done a lot of painting in my 23 years of marriage. And it happens that the small bedroom also has the smallest furniture, making it easy to clear the room. Painting the small bedroom is going to be harder than “Do the dishes” or “Clean the bathroom” (1SP). I think it’s a little harder than “Pick up leaves in the garden” (2SP) because I know that the clean up can be a problem. However, I don’t think painting a room is harder than “Clean the fireplace” or “Switch winter clothing for summer clothing.” (3SP). So, this story gets 3 story points.

One more example – STORY 105. We need to fix some problems on the roof. Honestly, I should probably hire someone else to do this, but that would mess up the example. I haven’t been on a roof since I was 15. I didn’t enjoy it. I don’t own a ladder (there’s a theme here – see it?). I can do the work – it’s been a long time, but I remember how. When I compare this to repairing the gate (5SP), the gate is definitely easier. In fact, I think this is going to be harder than repairing mortar between bricks (8SP). I need something bigger than 8SP. I’m allowed to use 1, 2, 3, 5, 8, 13, 21,… for my story point values. So, how much harder is repairing the roof to repairing the bricks. A little? A lot? I’m going to go with a little harder. So we’re going to call this story a 13 story point story.

That’s pretty much how estimation works. We discuss the item with the Product Owner to make sure we understand it. Then we compare how difficult or complex, risky, or big we think the backlog item is to backlog items we’ve already estimated. It’s not a precise science, but since estimates are wrong anyway, these are as good as any other and they cost a lot less money and time to create than estimates based on solving the item and determining the necessary effort.

With thanks to Mike Cohn for the properties (complexity, risk, bigness) to be used when estimating user stories!

Be sure to continue by reading part five!

Don’t Miss Your Opportunity!

Don’t miss your opportunity to become the user story maestro your team needs—register for our “Amazing Stories! 1” today! Amazing Stories 1 is your essential guide to writing effective user stories. This is your golden ticket to mastering the art of writing effective user stories that drive your Agile projects to unparalleled success!