At its most basic level, Agile product development or delivery consists of a product owner, dev (development) team, and stakeholders. For Agile to stay genuinely, well, agile, all of these elements must play their part equally.
Developer and Agile/lean coach Henrik Kniberg takes us on an easy-to-digest journey through Agile product development from the perspective of, arguably, the conductor of the entire operation: the product owner.
Read on for the breakdown!
Managing the Story Funnel
This is essentially the most critical part of an Agile product owner’s job.
In Kniberg’s example, he uses a single development team of a size able to tackle around 4 to 6 user stories a week. But every time they deliver a set of stories to the stakeholders, those stakeholders have even more ideas they want to turn into stories. If those stories get added to the funnel of stories waiting for the team to tackle, there’s quickly going to be a backlog.
This will lead to multitasking, demotivation, lower output, and lower quality. And you don’t want that!
Learn to Say No!
It’s up to the product owner to say “no” to the stakeholders. As Kniberg notes, “saying yes to a new feature request is easy especially if it only means adding it to an ever-growing backlog the most important job of the product owner is to decide what NOT to build and taking the consequences of that decision.”
The product owner facilitates a short feedback loop between stakeholders, themselves, and the development team. They:
- Ensure everybody understands the vision (the big picture)
- Gives the team direct access to the stakeholders
- Encourage frequent deliveries to real users
Knowing Which Trade-Offs to Make
Of course, this will mean making decisions about what to prioritize over what. According to Kniberg, some common Agile product development trade-offs scenarios include:
- Business risk vs. social risk vs. technical risk: Are we building the right thing? Can we build it? Will it work on the platform we want to run it on? Will it scale?
- Cost vs. schedule risk: “Can we finish the product in a reasonable amount of time for a reasonable amount of money?”
- Knowledge value vs. customer value: What the team knows and learns vs. what the client deems valuable to their business (and a client may cut the tail on a project at any time)
- Short-term thinking vs. long-term thinking: What should we build or fix next?
- Building the right thing vs. building the thing right vs. building it fast: Ideally, you want to try to balance all three, but that’s not always possible, so the product owner needs to manage this area carefully.
- New product development vs. old product improvement: A project is never really finished, so product owners need to decide what, when, and if to maintain something.
Keeping in Touch
The beauty about Agile is that even if the project is more extensive and encompasses multiple teams, the product owner’s job (and every other cog in the product development wheel) remains essentially the same.
After all, “velocity is really the sum of all output,” Kniberg notes. “So that can be used for forecasting or make a separate forecast for each team if that makes more sense.”
But now that there are multiple product owners (linked to the aforementioned multiple teams), they have one additional responsibility. They need to talk to each other to sensibly sync what’s being built and when—a job often left to the Chief Product Owner (CPO).
Do you find Kniberg’s breakdown of agile product ownership insightful? Or do you think he simplifies the process too much?
We want to hear your thoughts and experiences. Share them (and this article) on your socials and drop us—Viral Octopus—a tag. And if you need more marketing advice, be sure to browse the other guru insights on this page.
