Focus on Benefits Rather than Features

Suppose your boss has not bought into trying an agile approach in your organization. You schedule a meeting with the boss, and stress how your organization should use Scrum because Scrum:

• Has short time boxes
• Relies on self-organization
• Includes three distinct roles

And based on this discussion, your boss isn’t interested.

Why? Because you focused on the features of Scrum rather than its benefits.

Product owners and Scrum teams make the same mistake when working with the product backlog. A feature is something that is in a product—a spell-checker is in a word processor. A benefit is something a user gets from of a product. By using a word processor, the user gets documents free from spelling errors. The spell-checker is the feature, mistake-free documents is the benefit.

It is generally considered a good practice for the items at the top of a product backlog to be small. Each must be small enough to fit into a sprint, and most teams will do at least a handful each sprint.

The risk here is that small items are much more likely to be features than benefits. When a Scrum team (and specifically its product owner) becomes overly focused on features, it is possible to lose sight of the benefits.

Scrum teams commonly mitigate this risk in two common ways. First, they leave stories as epics until they move toward the top of the product. Second, they include a so-that clause in their user stories. These help, but do not fully eliminate the risk.

Let’s return to your attempt to convince your boss to let your team use Scrum. Imagine you had focused on the benefits of Scrum rather than its features. You told your boss how using Scrum would lead to more successful products, more productive teams, higher quality software, more satisfied stakeholders, happier teams, and so on.

Can you see how that conversation would have gone differently than one focused on short time boxes, self-organization and roles?