June 17, 2013

The Product Owner (PO) Board - making PO workflow visible

The transparency brought about by the Product Owner Board brings to the PO team many of the benefits we see with development teams

One of the principles of agility is transparency - making the flow of work visible. It is common for the development team to use task boards and burndown charts, and we've found that extending this practice to the product management team is just as valuable. No surprise there.

We have found this to be especially valuable, as the PO Team tends to be less agile due to their background. Most accept that the dev team is doing something weird and that they are required to provide different “specifications” but if you manage to set up a board and make their work more transparent, it is a vital step towards true agility for the POs and therefore for the whole organization.

However, the PO Board itself has some subtleties that reflect the needs of the product management team. The PO Board provides the context for working on a specific product. In particular, by combining the product vision and the emerging requirements and features the PO Board allows incoming work to be simply and easily cross-checked with the product strategy, keeping a focus on the long-term aims of the product, rather than near-term distractions.

Starting with a clear description of the product vision, including the requirements identified to deliver on that vision, the PO Board always includes the contextual information required to decide whether a feature or work request should be included in the backlog and worked on by the product management team, let alone the development team.

The Product Owner board

Beneath the product vision and requirements, we capture all feature requests associated with the product. At this stage, no prioritization is used. This is simply our someday-maybe pile for consideration in the future.

As we begin release planning, the features in the someday-maybe pool are moved to the beginning of the task board in order of priority. Depending on the agreed process for integrating new ideas, the board will have a number of columns describing the stages a new idea goes through: investigation and sharing with the architects and technical leads, or the customers and stakeholders during the elicitation and definition process.

The result is a feature board that exposes the progress made on defining, grooming, developing and deploying product features (see diagram). Starting from the top left, the highest priority feature is defined, split into stories, discussed and groomed with the team, and eventually enters the team's backlog. As we move down the board, we can see when the next release will be complete and what it, and the one or two releases after that, will contain. As we move across the board, we can see where each feature is in the definition process.


Product Owner comment

Several things become clear when the PO Board is used.


- First, the team no longer considers the grooming and backlog definition process something that happens right before the team starts work. The depth of research, requirements definition and preparatory work becomes much more clear. In fact, in one client we worked with, the PO Board allowed the organization to see how poorly staffed the product management team was (queues forming long before stories hit the development team's backlog).
- Second, queues can be allowed where there are quality gates, traditionally defined by a form of Definition of Done, which helps clarify hand-off between columns (and in particular, between different teams/individuals): For stories ready to be groomed and sized, we use a Definition of Ready; For stories that are complete, but not fully integrated or acceptance tested, we use a Story Definition of Done; For stories accepted by the customer and ready for deployment, we use a Release Definition of Done. 

In conclusion, the transparency brought about by the PO Board brings to the PO team many of the benefits we see with development teams. It quickly exposes dysfunction, bottlenecks and inaccurate assumptions. It acts as a brake on starting urgent tasks over important tasks. It reinforces the need to focus on a small number of items at any one time. It encompasses the entire value chain, focussing on delivery to the customer rather than the development team. And of course, it introduces agile principles to teams outside core development.

 

Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.
blog comments powered by Disqus
Image of davesharrock

Dave Sharrock

Agile coach passionate about getting things done; helping teams exceed expectations, delivering organizational excellence, and all while having fun doing what they do.

Latest Posts

Niels Verdonk, new Certified Scrum Trainer in the Netherlands

Niels Verdonk has qualified as a Scrum Alliance Certified Scrum Trainer

Image of andreat

Andrea Tomasini

I am an Agile Coach and Trainer and I am helping customers all around the world to become more Agile. I am more and more keen on adopting adaptive emergent approaches to improve people's quality of life. Through an holistic and pragmatic approach - I consider Lean and Agile very powerful frameworks - it is possible to improve results, performance and also personal satisfaction.

Sponsoring Manage Agile 2017

agile42 is a sponsor of Manage Agile 2017 conference in Berlin for managers in agile companies

Image of marion

Marion Eickmann

I am one of the founders of agile42. Even though I am not an engineer I consider myself almost a "Techi" as I have been working in the field of software development for 10 years now.

Joanne Perold keynote at Regional Scrum Gathering 2017

Coach Joanne Perold presenting at SGZA17, the Regional Scrum Gathering South Africa 2017

Image of peterhundermark

Peter Hundermark

Peter has worked with iterative and incremental software development processes since 1999, focusing on Scrum and Agile practices since 2006. In 2007 he started Scrum Sense in South Africa. He has introduced Scrum into scores of development teams locally and in Brazil. He leads certified Scrum training classes in South Africa and elsewhere. He is a Certified Scrum Coach and Certified Scrum Trainer.

Scrumtisch January 2018

The Berlin Scrum User Group meets on January 24th at SAP in Rosenthaler Str.

Image of aballer

Alexandra Baller

agile42 Team Assistant

Coaching structures in Tampere

Martin von Weissenberg delivered a presentation about Coaching Cards and the agile42 Coaching Structure at Tampere Goes Agile 2017

Image of mvonweis

Martin von Weissenberg

Martin helps people understand agile and lean thinking and coaches teams and organizations in the use of agile methods and practices. He is a Scrum Alliance Certified Enterprise Coach (CEC) and is working on a PhD on how to manage and organize for agility.