The Power of Scrum - The Backlog and Product Owner

The more I work with teams and use Scrum to deliver software solutions, the more impressed I am with the simplicity and power of Scrum. I thought I would take some time to blog about some of the more powerful points. I will start with the Backlog and Product Owner.

Build the Right Thing

In this competitive world, one of the major risks we face is, are we building the right thing? This has two important aspects to it.
On one hand, are we including the most important features for our product? If we miss an important feature, we may miss a competitive opportunity and lose market share. Our competitors may beat us to the punch.
Or perhaps we are building many features, but not the ones that really add value. We could be very efficient, and deliver features on time and within budget. However, if these features are things our customers do not need, it has been a waste.

The Product Owner

Scrum has a role that focuses specifically on this challenge. The Product Owner is the person who understands the Product being delivered better than anyone. She understands the competitive marketplace and understands what features are important for the Product. These features are maintained in a prioritized list known as the Product Backlog.

The Product Backlog

The backlog is fluid and changes often. As the Product Owner conducts surveys and interviews stake holders, the features on the backlog and their priority change.

This sets Scrum apart from more traditional development approaches where we define what we need up front and consider most changes as an unwelcome event. Scrum embraces change and accommodates it as a core principle.

Stop at Any Time

Since the backlog is prioritized, the most important and valuable features are at the top. This means as we move down the backlog delivering features that are a bit less valuable than the previous ones, we can stop at any time.

When we have delivered enough value, what ever that is, we can stop. This also sets Scrum apart. Under more traditional delivery approaches, we deliver everything we defined at the beginning of the project, even if a feature is rarely used.