The Product Backlog: Your Compass for Shifting Business Priorities

Find me on: 
LinkedIn Twitter

Many software teams fail to produce the right functionality to drive the priorities of the business. After months or even years of work, they’ll show the finished product to stakeholders only to hear, “That’s not what I wanted.”

The team coded against the specification and they felt pretty good about how well the product functionality matched what’s in the document. Confused by their reaction, the team may ask for an explanation and stakeholders respond, “Things changed since that spec was written” or “I was thinking it would work differently.”

The problem is threefold with traditional waterfall software development:

  • Features are seldom force-ranked by business value, so teams spend too much time on functionality that produces little return on investment.
  • Too much time goes by between the spec being written and the stakeholders seeing working, shippable software. By the time they provide feedback, it’s too late to make substantial changes.
  • There isn’t enough interaction between business visionaries and the development team to keep them informed about changing priorities along the way.

When used correctly, the product backlog solves these problems by creating a shared vision with business stakeholders and the team throughout the development of the product. Interaction between the product owner and the development team happens throughout every day. This ensures the needs of the business are directly connected to the ongoing development work throughout the entire process. 

Finally—and probably the most important—the product owner places the most valuable stories at the top of the backlog. This ensures items that generate business value are completed first and are delivered sooner rather than later. This prevents less important items stealing development time from other, more profitable user stories.

The Single Shared Source of Truth

The product backlog provides a shared “source of truth” as it pertains to the vision for the product. It allows both the business stakeholders and development team to always understand the vision for the product.

Types of Items on the Product Backlog

The backlog contains three different types of items: user stories, tasks, and bugs.

  • User stories are lightweight requirements that represent new functionality that delivers value to business stakeholders; including end users. For example, “As a Shopper, I want to check out, so I can get my products shipped to me.”
  • Tasks represent items the development team would like to do, that provide direct value to the team and indirect value to business stakeholders. By managing this type of work on the product backlog, it provides visibility to the product owner and allows him to properly prioritize it. For example, “Update developer workstations to the latest version of coding tools.”
  • Bugs are defects that made it into the product when it was deemed shippable in a prior sprint—bugs that made it through the development team’s testing process undetected. For example, “Search results are incorrect if I enter two words separated by a space.”

Discussing the Backlog with the Team is Important

Most development team members don’t spend as much time reading project documentation as we’d like. To combat human nature, instead of assuming the team will read the documentation, we talk about the product vision instead.

The process of refining the product backlog—sometimes also called grooming the backlog—happens throughout the development of the product. Most Scrum teams get together one or two times during each sprint to talk about what’s coming up next on the product backlog.

Backlog refinement has the following benefits:

  • The product owner can explain the vision for each upcoming story.
  • The team can ask questions to get more details.
  • Because the team will be on the same page, the planning process will take less time.
  • If there is anything confusing or open questions from the development team, the product owner has some time to get things straightened out before the next sprint planning ceremony.

Collectively, this discussion does what I call “programming the team’s collective subconscious.” It gets everyone thinking about what’s coming up next and, in the back of their minds, they’ll start thinking about how they might build it during the next sprint.

Requirements Evolve Over Time

The comprehensive software specifications that are common with waterfall projects assume that requirements can be nailed down at the beginning and remain largely unchanged.

Scrum acknowledges the high-risk nature of software development and instead of attempting to lock things down for long spans of time, it says, “Let’s embrace change.” The product backlog is in a constant state of evolution. The only requirement to “lock down” a portion of the product is for the scope of work in the very next sprint, ranging from one week to a calendar month.

What are your thoughts? What do you think are the key factors that lead to the dreaded sentence from stakeholders “That’s not what I wanted”? Leave a comment below.


Comments