Product Owners: Understanding who the real MVP is – Part One

Part One

This is the first of a two-part series on product owners, what they do, how they do it, and why they’re so often vital to the success of development.
—

A good product owner plays a critical role in agile development structures and separates mediocre development results from the great. To understand what product owners truly bring to the table, it’s important to consider how agile development works from their perspective.

The Context

A product owner has a vision about the desired end creation and the stakeholders (those affected by the product) have lots of ideas about what the product should do. The stakeholders’ needs are expressed neatly through user stories – a map or guide that arranges these needs into an easy-to-follow model to help understand the functionality of the system, identify holes and omissions in the backlog (more on this later), and effectively plan holistic releases that deliver value to users and the business. Typically a user story will follow this formula:

As a {type of user}, I want {to perform some task} so that I can {achieve some goal/benefit/value}
(Scrum Alliance)

The product owner is responsible for making sure user stories have actual value and are sufficiently prepared to be passed on to the development team.

Teams and Sprints

Any product needs people to build it. In agile software development, cross-functional and self-organizing development teams make the products. These teams usually works to release continuous iterations of a product during phases called sprints. Typically, sprints take around two weeks and the number of user story points released within each sprint is the team’s capacity. Teams may release around five to fifteen stories per sprint but this can change depending on the kinds of changes and stories the product requires.

Twenty user stories is generally the upper limit and this usually occurs in a web team with lots of small changes to do. Anything more than that is probably too much, unless it’s for maintenance teams to knock out a backlog of small defects. As a rule of thumb, exceeding the upper limit usually means the stories are not clear enough, the sprint is too unrealistic, or the definition of “done” is too weak.

Most individual user stories shouldn’t take more than half the sprint to develop and test. Having multiple stories that take up more than half the sprint at the same time is risky, and in that case all the other stories should be very small. For a two-week sprint, it’s better if every story can be completed in one to three days. (Adjustable for longer sprints.)

“Yesterday’s Weather”

The leading ailment of sprints is when stakeholders and everyone else with a vested interest in the project ask for more, and ask for it in waves. As the development team releases iterations, it’s only natural that the stakeholders become more inspired. Still, as much as it’s unreasonable to ask stakeholders to figure out all their ideas at the start of the first sprint, it’s just as frustrating for development teams to aim for targets that move. Imagination changes on the go, and ideas can’t always fit on a development team’s plate.

As a result, teams that have a capacity of five to seven user stories per week won’t perform well with stakeholders pushing ten. This kind of overloading can cause some serious miscommunications, misaligned expectations, and lower quality results.

The way to avoid this is a method known as ‘Yesterday’s Weather’.

The development team says, “The past couple of weeks we’ve been finishing around five to seven user stories per week, so let’s say six is our optimum number that we can work on simultaneously.” Six is now their work in progress (WIP) limit, which is the maximum amount of work that can exist in each status of a workflow. When they finish one user story they start on another one. Finish two, pick up two more, and so on.

Strict task limits force teams to focus on smaller sets of tasks, causing increases to throughput and reductions to the amount of work that hangs in the “nearly done” category. At a fundamental level, WIP limits encourage a culture of “done,” which can be satisfying for everyone involved. Additionally, WIP limits also boost the visibility of bottlenecks and other elements that stifle progress. Teams can then clearly understand what is being blocked, why and how that’s the case, and develop a resolution strategy. Minimizing the delay of blockages allows the entire team to keep a steady pace and workflow.

The Product Backlog

If a team gets too ambitious and breaks its WIP limit, fast can turn to slow, accuracy can turn into sloppiness, and output can start to leak or fall behind. The resulting consequence is the formation of unfinished user stories into a queue known as the product backlog.

This is often where the product owner becomes the center of attention because this queue needs to be both managed and prioritized, which was not an issue previously. At this point, the sprint planning meetings need to address the level of urgency on new and backlogged tasks at the same time. In doing so, product owners attempt to strike a balance of eliminating the backlog while also moving the overall development forward at the same effectiveness – which is not an easy task.

To ensure that the product backlog doesn’t get wildly out of control, the product owner must start to say “No” to certain stakeholder desires. If the product owner isn’t from the side of the client, he/she may not have the necessary authority to make these decisions. In such cases, it’s up to the product owner to successfully convince stakeholders to prioritize backlogged items. All of this potential conflict helps support the importance of sticking to the WIP limits.

This is the end of part one. Be sure to read part two on intelligent prioritization, the feedback loop, the juggling of multiple projects, and the management of expectations.