The Backlog: One Idea; Three Definitions

There are so many terms in technology. That would not be a problem if language were a perfect science. Alas, it is not. Let’s just think about “product backlog.”

The Scrum Alliance provides this definition:

“The product backlog (or "backlog") is the requirements for a system, expressed as a prioritized list of product backlog Items. These included both functional and non-functional customer requirements, as well as technical team-generated requirements”

Wikipedia says:

“The set of features that go into each sprint come from the product backlog, which is a prioritized set of high level requirements of work to be done.”

At Control Chaos, they say:

“Product Backlog (or, backlog) consists of all features, functions, technology, bugs that will constitute the product once the work has been done in Sprints to turn this backlog into software”

So, it looks like there is general agreement that the backlog is a prioritized list of things that need to get done in order to move our product in the right direction.

And yet – there is general chaos surrounding this artifact in most agile environments. We throw around terms like “requirements,” “features,” “functions,” and “technology” so frequently that they don’t really have a clear definition anymore. One’s definitions are dictated by our experiences and education, rather than any standard description that we can rely on.

To ensure clarity on our teams, it’s helpful to examine and discuss examples rather than terms.

Mike Kohn provided a few examples in a recently published article. The article is a good read with several good points. He explains that clarity should increase on backlog items as the sprint gets closer. If we have complex items, it makes sense to take time during prior sprints to figure out the full breadth of user stories, so that when we’re ready to work on this item we’re ready to go. Furthermore, he relies on a User Experience Designer to clarify the items. Let’s take a look at his examples.

Mike’s two examples of backlog items:

• As a user I can see the current version, company website, and copyright in a "help about" dialog so that I know useful information about the product.


• As a user I can enter a check in my register so that I can track who I pay.

These statements are already at the feature level. It doesn’t define exactly what the screens will look like, but someone has decided that important user information will go in a screen called “help about”. Likewise, someone has taken the time to start defining the necessary tasks included in managing a checkbook.

Where do these items come from?

When a Product Manager studies the market, they discover groups of people who share common problems. When they quantitatively analyze those problems, some are proven to be urgent, pervasive problems that people are willing to pay to solve.

The Product Manager’s primary job is to discover problems with these characteristics, then describe those problems to their organization. One part of their job is to define these problems for the Marketing and Sales organizations. The other part is defining the problems for Development, in a way that allows them to build the best possible solution, a solution that resonates in the marketplace and makes our target buyers come running.

For Mike’s example, he says that they’re building a checkbook program to compete with Quicken. I’m going to set aside the problem of entering an already swamped market and attempting to compete with the big boys. Let’s instead think about the Product Manager in this organization. If they’ve studied the market, perhaps they’ve found some problems that are urgent, pervasive, and have buyers willing to pay for a solution. The Product Manager would analyze the market evidence, and eventually write requirements. These requirements state that “Every [frequency], [persona] has [problem] with [result].”

Restating the earlier example: Once or twice in a year and usually on the initial visit, Sally the Soccer Mom wants to know more about the company, including where they are located physically and how they can be reached electronically. She needs this information when she has a problem with the product, or when she decides to upgrade.

In Mike’s fictional company, another primary requirement might state “At least once a week, Sally the Soccer Mom needs to figure out her current checking balance so that she knows if she needs to transfer money into the account. Otherwise, she might bounce a check or get charged overdraft fees.”

An interaction designer could take this requirement (along with the fully defined description of the persona, Sally the Soccer Mom), and design an interface that solves the defined problem. One item would be that the user needs to enter checks she has written. That capability is necessary in order to provide a current balance and solve her real problem – she doesn’t want to bounce a check or pay overdraft fees.

How often have you already envisioned the solution before you’ve stated the problem? Begin with the problem-oriented requirement: “Every [frequency], [persona] has [problem] with [result].” Then work with a user interaction designer or business analyst to define the solution.

If you define product backlog items at the level presented in Mike’s example, you’ll need a user interaction designer to translate the requirements into the product backlog items – otherwise, the Product Manager is being asked to focus internally, when our company is much better served by our presence in the market.