Inconsistent PBI Formats

The Scrum Guide doesn’t require you to use a specific format for your product backlog, but having a consistent PBI format keeps the backlog organized and makes it easier to interpret.

You’ll spend a lot of time working with the product owner and development team to come up with a standard format. You may decide to use different formats for different types of work. (For example, a bug might have an attribute for reproduction steps whereas a new feature might have a value attribute.) Just be sure to use a consistent format for each type of work in your product backlog.

Here are some examples of attributes you might decide to require for a new feature:

• Title
• Description
• Acceptance Criteria
• Estimate
• Value

Joe asks:

You keep mentioning estimates, but don’t you mean story points?

Story points are just a method for creating estimates. Story points were created by Ron Jeffries to help make estimating easier for Scrum teams. The basic idea behind them is that, instead of estimating a product backlog item in hours, the Scrum team only considers how much effort a PBI will require relative to other PBIs. Teams often use the numbers in the Fibonacci sequence (1, 2, 3, 5, 8, 13) as values for their relative estimates. They’ll score work that they think will require less in effort as a 1 or 2, and score more complex work that requires more effort a higher number like an 8 or 13. Teams often use [planning poker](https://en.wikipedia.org/wiki/Planning_poker) to facilitate story-point estimation. The Scrum Guide is silent on how you should estimate work. You can use hours, T-shirt sizes, or story points, or even just mark every product backlog item as a 1 and count how many items you finish in a sprint. Regardless of what technique your team uses, you need to create estimates so the development teams can get a sense of how much work they can pull into a sprint. Remember, estimating is really about the conversations the development team has about their work, and about empowering the product owner to forecast and plan. Exactly how your team creates those estimates is inconsequential.

Here’s a product backlog item format that a lot of Scrum teams use—it was created at Connextra^[11] in 2001:

“As a (role), I want (behavior), so that I get (business value).”

So what does this format look like in practice? Let’s check out an example of a PBI that could end up in a product backlog. But first, some context: Ryan and Todd both teach a lot of Scrum classes, and we need a tool to help us manage our classes. Here’s one possible product backlog item that we could decide to order high in our product backlog for this project:

As a Scrum trainer, I want to create a new listing for a Scrum training class so that potential students can get information about the course.

Details: The Scrum trainer needs to be able to enter and edit the following information:

• Course name
• Course description
• Scrum trainer name(s)
• Course location (address)
• Course start date
• Course end date
• A link to register for the course (currently handled through a third-party payment processor)

Value: High - ability to find and register for a course - direct link to revenue Estimate: Development team estimates five story points for this PBI. The current platform supports the majority of the requested functionality.

As you gather PBIs, your product backlog can start to look like a flat, one-dimensional list that can be challenging to decipher, especially when you consider that the items will be at various level of clarity (story, feature, epic)—in other words, broken down into different levels of detail. To help keep things clear, you can create a list of product backlog items sorted by which level of understanding (decomposition) each PBI is currently in that can be read and understood by the Scrum team and stakeholders.

What’s up with that Payroll item? Great question. In this example, payroll is an epic that’s many months away from being considered for a sprint. The Scrum team knows that they need to do the work eventually, but they’re not sure what that work looks like yet.

Regardless of the terminology or the format that your team chooses for product backlog items, it’s important to be consistent.