Creating a Great Product Backlog

Your team creates a product backlog, which usually contains use cases, to represent what its customers need and value. Over the course of the project, your team will add detailed information to the use cases, break them down into other use cases, prioritize and estimate them, and finally, implement them and deliver the results to your customers. By writing great use cases and continuously updating the product backlog, your team can more effectively deliver value to your customers.

When your team creates a use case, make sure that it represents customer value by answering the following questions:

  • Who the user is

  • What the user needs to do

  • Why the user needs to do that

The use cases should also be defined in a way that allows them to be implemented in any order. However, it is not always practical to make the use cases completely independent.

Use cases that are valuable and independent, as previously described, make up the project backlog. They are estimated and prioritized, and then your team starts to work on the highest ranked use cases. Before your team implements a use case, it must have the characteristics in the following list. Your product owner will work to make sure that the use cases that are ranked highest meet these criteria before bringing them to a sprint planning meeting.

  • Small enough to be implemented in the sprint

    Use cases that are about to be implemented must be small enough to be finished in the sprint. Your product owner will work with your team to break down use cases that are too large. For example, the use case “As a customer support representative, I need access to customer information so that I can more quickly respond to customer questions” may be too large to finish in a sprint. It could be broken down into smaller uses cases or scenarios such as “As a customer support representative, I need to access the customer’s name and the recent call summary by using the customer's phone number” and “As a customer support representative, I need to access the customers’ full call history so that I can research the current problem in more detail.”

  • Just detailed enough to describe and estimate the work that is required to implement the use case

    Before they are included in a sprint, use cases are estimated in story points. These are intentionally rough estimates that are primarily used to manage the backlog and to help prepare for the sprint. When a sprint starts, your team will break the use case down into the tasks that are required to implement it. Your team will work with your product owner in the project backlog grooming meeting to determine which use cases need more information before they can be broken down into tasks to estimate the hours of work. Your product owner can gather these details and record them in the use case’s description.

    Be careful not to add more details to the use case than necessary. The use case should be the basis for a conversation and negotiation with your product owner and customers that continues until the use case has been finished and accepted. Too much detail can impair the negotiation by creating an implication of precision that is not accurate.

  • Acceptance criteria defined

    At the end of a sprint, your customers or your product owner will either accept the use case as finished or reject it. Before the sprint starts, the criteria for customer acceptance should be described as clearly as possible. Of course, a use case may not be accepted for reasons that were not anticipated. However, the conversations that your team has with customers to help define the acceptance criteria will help ensure that your team understands your customers’ expectations. The acceptance criteria can be used as the basis for acceptance tests so that you can more effectively evaluate whether you are finished with a use case.

Epics and Themes

It is frequently said that use cases should be small. That is true for the use cases that are about to be implemented. However, the use cases that are ranked lower can be larger. In fact, keeping them large is a good way to keep your product backlog from becoming too large to manage. Use cases can be broken down into smaller use cases as they approach the top of the prioritized product backlog. It is helpful to think of large use cases as epics and themes.

  • Epics are very large use cases that represent a significant amount of work. When you break an epic down, you may create many themes and other, smaller use cases.

  • Themes are use cases that are fairly large, generally larger than you would implement in a sprint. Before your team implements a theme, it must be broken down into smaller use cases.

When you prioritize the project backlog, break down epics and themes that are near the top, and prioritize the new, smaller use cases. When you are finished, the highest priority use cases should be small enough to implement. Lower in the prioritized backlog, most of the use cases are generally larger.

See Also