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 specifications. They felt pretty good about how well the product functionality matched what was in the document. When asked for clarification, the 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. 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. It’s too late to make substantial changes by the time they provide feedback.
- 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. The product backlog creates 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 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 delivered sooner rather than later. This prevents less important items from 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 the development team to always understand the priority of features, and the benefits of those features to the end-user.
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. Managing this type of work on the product backlog provides visibility to the product owner, allowing him to prioritize it properly. 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. Instead of assuming the team will read the documentation, we talk about the product vision together to combat human nature.
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. This is beneficial 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 are 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. 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. 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”? Contact us if you’d like to discuss!
