Video notes: Agile Product Ownership in a Nutshell

This 16-minute video by Henrik Kniberg is a great overview of the agile software development process, but also contains lots of smaller great insights.

Table of contents

The video

Watch Agile Product Ownership in a Nutshell (15:51) on YouTube.

I found the video via Critter's blog post Pull methodology, flow time, and WIP limits: visualized.

Top 3 moments

The 16-minute video is packed with great insights. I guess different things would stand out when rewatching the video later; this time these three things resonated with me the most.

Knowledge focus vs customer value focus (8:12–9:16)

Knowledge can be seen as the opposite of risk, so when uncertainty is high, our focus is [on] knowledge acquisition; we focus on things like UI prototypes and technical spikes/experiments. Maybe not too exciting for the customers [(stakeholders)], but still valuable because we are reducing risk. From a customer value perspective, the curve [of customer value (y-axis) and time (x-axis)] looks [flat] in the beginning.

As uncertainty is reduced, we gradually focus more and more on customer value; we know what we are going to build and how, so just do it. And by doing the highest-value [user] stories first, we get this nice steep value curve.

And then gradually the value curve starts flattening out. We have built the most important stuff, and now we are just adding the bonus features; the toppings of an ice cream. This is a nice place to be [in] because at any point [the Product Owner] and the team may decide to "trim the tail," to cut right here and move on to another more important project. Or maybe start a whole new feature area within the same product. That is business agility.

So when I talk about value [of user stories], I actually mean knowledge value + customer value. And we need to continuously find the trade-off between these two.

Correct vs good vs fast (9:39–10:42)

Should we focus on:

• building the right thing
• or building the thing right
• or perhaps building it fast?

Ideally we want all three, but it's hard to find the balance.

[...]

• Product owners tend to focus on building the right thing.
• Development teams tend to focus on building the thing right.
• Scrum masters or agile coaches tend to focus on shortening the feedback loop.

Speed is actually worth emphasizing because a short feedback loop will accelerate learning, so you'll more quickly learn what the right thing is and how to build it right.

However, all three aspects are important, so keep trying to find the balance.

Reducing scope vs extending time (13:15–14:00)

Suppose a stakeholder says: "Can we get these features by Christmas?" Now, that's a fixed time, fixed scope question.

Looking at trend lines, [the Product Owner] says: "Nope, sorry, ain't gonna happen," followed by, "here's how much we can get done by Christmas" or "here's how much more time we would need to get everything done."

It's generally better to reduce scope than to extend time, because if we reduce scope first, we still have the option to extend the time later and add the rest of the [user] stories.

Vice versa doesn't work because, darn it, we can't turn the clock backwards. [...]

So, [the Product Owner] puts it this way: "We could deliver something [soon] and the rest later, or we could deliver nothing [soon] and the rest later; which do you prefer?"