I consider communication to be one of the prime directive elements of solid product ownership. Now an important part of that communication is leveraging the natural Scrum ceremonies/meetings to their full effect.  One that I think is particularly important is the sprint demo or review. This is THE event for a Scrum team to show their results and speak to progress and future plans. Sometimes I call that “connecting the dots” for their stakeholders.

A good Project Manager usually pulls together something called a communications plan. This plan highlights the communication channels, responsibilities and people for the project. It’s usually too heavy weight for most agile projects, but the intent of the thing is very sound. In Scrum, most if not all of this communication falls to the Product Owner. Here we explore aspects of effective communication.

While it might strike you as odd, I include listening as a crucial part of communication. Perhaps unfairly because I’m using my own style as a factor – meaning: I talk too much. So I want to remind Product Owners that they need to continuously sharpen their listening skills. And an important part of listening is observing “body language” and what isn’t being said as well.

Sprint Review

• Are we continuously demonstrating working software, while absolutely adhering to our Definition of Done?
• Has there been sign-off and acceptance of all of the work. And did the team meet their sprint goals?
• Are key stakeholders always in attendance for the sprint review? And not just in attendance, but full engaged, asking question and providing feedback?
• Are you tying the results to your release plan? Connecting the dots if you will to previous sprint results and forward to what you’re planning to do next?

Communication

• Are effective information radiators in place and is the organization “listening” to them? One way to measure this is if you’re getting questions around your teams’ artifacts.
• Does the team share congruent, open, and honest feedback in the sprint retrospectives? One of the key challenges is for the Product Owner to not be too “pushy” regarding business needs, which stifles communication.
• Is the Product Owner an active “publicist” for the team down, around, and up within the organization? Do senior leaders and key stakeholders always come to the PO to find out where things stand?

Listening

• Engagement levels in retrospective. Bringing personal, business, and value views into the teams purview for improvement consideration
• Actively incorporating team feedback into the Product Backlog via stories, ordering, strategy, and efforts to address technical debt.
• Attend sprint and release planning meetings. Listen attentively to team discussions around technical design, trade-offs, architecture, and level of complexity. Both from a development and testing perspective.

The steering practices are just that – focused towards steering the efforts of the team towards business and customer-centric goals.

The first area of consideration is product mentoring and establishing a product owner centric Community of Practice. This is where standards are kept and lessons learned are shared. Where product owners mentor each other towards consistency in execution, but also in guiding and leading the entire organization.

Another critical steering area I call envisioning. This is where projects are essentially chartered and the project level goals, constraints, and conditions of acceptance are identified and explored. If you are familiar with the practice of Story-Mapping, it would be an envisioning practice for the Product Owner and their team(s).

Finally, release planning towards establishing and committing to road-maps is the final envisioning practice. Not only is this for the team to establish a shared view towards their strategies, but it’s necessary for the Product Owner to communicate the game plan and commitments to stakeholders and customers.

Far too often, agile teams “dive in” to projects and initiatives without truly plotting where they are going. The steering practices focus on avoiding that common anti-pattern.

Product Mentoring and Community of Practice

• A CoP is established to guide consistency across Product Ownership artifacts (backlogs, stories, road-maps, etc.) and activities (story writing standards, grooming / refinement meetings, release planning, etc.)
• Product Owners collaborate as a team. To use Spotify terms, they form a “Chapter” that is intended to guide the practice of Scrum product ownership. In other words, they actively pair and mentor one another.
• There is a tendency within agile contexts to reduce or remove standards and templates. Here the product organization established healthy and balanced standards that aren’t too restrictive to team performance.

Envisioning

• Mission and vision for all project-level activity is clearly communicated by leadership and then activated by the product organization. The teams need to be able to “see” the mission and vision.
• Some form of project chartering is used to begin or instantiate each project initiative. Often this is a prerequisite for release planning initiatives. (in SAFe, there is a clear notion of chartering within the PSI Planning activity. This is a good example of the point…)
• Notions of Minimal Marketable and Minimal Viable are regularly used to communicate the focus and goals of the project. Included with this effort is Story-Mapping to envision how the functionality will unfold and solve the customers’ challenges.

Release Planning & Road-mapping

• Here we move from looking at the Product Backlog as a “series of requirements or features” to a dynamic flow of work directed towards achieving the businesses’ objectives.
• Having a balance between features, technical investment, and technical debt buy-down activity. Another part of this is committing to fight “feature-it is” as the only way to load the backlog.
• Release planning is a whole team activity that leads to road-mapping and commitments to the business regarding deliverables. Point being, the team is engaged in the envisioning, delivery planning and commitments. And the business realized that there is variability in the commitments.

Wrapping Up

There you have it. We explored four areas of product owner maturity and three central practices within each. The intent of this article was to expose you to my AJI-extensions for Product Owners. Remember it’s a framework and intended for healthy improvement of your practices.

Not only am I hopeful that I made you think about Product Ownership maturity, but I hope I inspired you to .

And not only to download it, but also to read through it and to possible use it in your organization.

And please remember, this is an iterative framework and I’m constantly learning and adjusting it. If you use it and have feedback towards improvement, ANY FEEDBACK, please take the time to send it to me. I promise to carefully consider it and incorporate it in the next edition of the framework.

Stay agile my friends,

Bob.