Lessons as a Proxy PO

Sometimes a challenge can be turned into an opportunity. When our team learned that the business needed to pull their popular Product Owner to focus on another team, a sense of panic set in. There would be a job search that could and did take months. Who would help the team on their path to creating value in the interim? How would we operate? Over time, what seems to be a negative turn of events was turned upside down. This is a story of how a team learned more about the Product Owner role and how they practiced collaborating better with their future Product Owner.

The start of this change was a simple thought. Using an old, trusted friend—the Scrum Guide—the solution emerged. The answer was based in the sentence “The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.” Could this concept flourish if we were all accountable? The organization agreed with the plan to have the team assume the role of the Product Owner and that I would coach them on how to do it.

Team Learning Objectives

The first task was to create a set of learning goals that could be reviewed and reflected upon as we embarked on our journey as a group of Proxy Product Owners. Over time we needed to increase our responsibilities by taking more ownership of the success of the product. We needed to ask questions of ourselves such as “Has the group done everything we can to improve the product?” and “Are we taking full ownership of this role and product?”

The desired outcome was to make our new Product Owner’s job easier and their onboarding quicker while still delivering value to the business. These were the learning goals that emerged over time:

1. Understand what Product Owners do to fulfill their role

2. Become more collaborative in story writing

3. Think more about refinement and the effect on planning

4. Look beyond the now toward the roadmap and upcoming work

5. Understand the benefits of Vision, Value, and Validation

Here is a list of actions the team took to fulfill these learning objectives.

Get Your Backlog in Order

A constant topic in refinement was the stale nature and size of the Product Backlog. There were 700+ items in it. Trying to order or understand that many items is beyond how our minds work. Some have suggested that around 150 items in a Product Backlog seems sensible, citing Dunbar's number. No matter the number, getting through 750 epics, stories, and defects even in three years was not possible based on the team's past data. The team felt many Product Backlog items were either outdated, had fuzzy descriptions, were redundant, were no longer required, or were already done. Many were not written by the team or written years ago. During a retrospective, the team decided to take action and clean it up. The entire team met one to two times a week for an hour. The team used a time-box of one minute to discuss each item. The categories were “Cancel,” “Talk More,” “Requires PO Prioritization,, and “Refine.” The “Talk More” category was used when the team could not agree on or determine a category within one minute and the item required a second pass at discussion. “Refine” was used when the item fit our near-term road map, technical debt, or defect priorities as these caused significant pain to the team or users. Here were the results:

Establish a Transparent Road Map That Is Updated Frequently

Setting expectations, making what is known visible, and revisiting the plan for the future are essential elements of creating a shared understanding of goals, the path to achieve the goals, and desired outcomes. In today's world of constant change, failing to inspect and adapt can lead to unmet expectations and not responding to change. During our biweekly refinement sessions and at sprint planning, the near-term road map was reviewed for changes and included discussing new information that could change that road map. Keeping our road map current, transparent, and available to Product Management allowed them to help us stay aligned with their vision and identify gaps in understanding. Using techniques like forecasting future sprints, reviewing each new request for value to set priority of refinement, and getting high-level estimates or identifying risks and knowledge gaps helped create or update possible timelines and trigger discussion. Below is a visualization of work requests given to the team categorized by how much we knew about the work and understood rough sizing of the effort. Included are: work in progress that has an expected duration; work that is blocked by external teams and cannot predicted when it will be completed; work that someone on the team has been involved in discussing and could give a “finger in the wind” sizing projection; work reviewed by the team that went through a sizing exercise as part of creating shared understanding; and work the team knows nothing about.

Use Rigorous Refinement Practices

One outcome that Product Owners drive toward, which was not being fulfilled, is being prepared for sprint planning. Instead of having a sprint or two of work that met the team's Definition of Ready, planning involved on-the-spot discussion and sizing of work that was not ready or forcing work to be reviewed quickly so there was enough to do. Another approach used was the concepts described in “Advancing the Story”. To cause change in preparation and execution, the following changes were introduced over time:

1. Regular scheduling of Refinement twice a week for an hour

2. Time boxes or discussing any item and tracking how many times an item is discussed. The time box was adjusted upwards to allow deeper conversation and completing refinement of simpler items. Tracking appearance at refinement identified items that needed more preparation, were too big, information from SMEs, or was more complex work. 

3. Defects description contains specific, detailed steps to reproduce if known, current behavior and expected outcomes the fix provides

4. Regularly review new requests for value and the need to add to our refinement backlog

5. Use of Given When Then format for items that had user interactions

6. For technical stories and discovery stories, the goal and expected outcomes that could be verified as true or false existed as Acceptance Criteria

7. Review and discussion of what properties make Acceptance Criteria effective

8. Tracking of action items to gather information of rewrite description in between refinement to continue advancing the story. The other intent was to change behavior of discussing future work only at team refinement sessions.

9. Focus on creating a shared understanding of the work goal and how it might be done across the entire team

10. Inviting SMEs, representatives from other teams, and internal users to help as needed

Discuss Value Always

Whether introduced as part of a new workstream, an improvement item, a defect, maintenance work, or technical debt, asking why the work is important to do soon and why the work is valuable to users or the team must be clearly articulated. If it cannot be articulated, decide if the work should be canceled or left in the backlog. When reviewing the near-term roadmap, check if there is new information that affects the value of the work and if other work needs attention first.

Effective Sprint Planning

While the team had started using Sprint Goals, they now were more responsible for creating them and could not sit back and listen to the Product Owner suggest it. They were the Product Owners. Instead of multiple goals, one true north direction was selected as the most important goal to achieve and to base decisions made during the sprint to achieve that goal.

In selecting which work to take on next, the team had to consider a few factors. First, the value of the work. Second, is it easier to execute now with related work fresh in our minds? Striking while the iron is hot can increase workflow and provide opportunities to reduce siloing within the team. Third, are we making progress on reducing our defects and technical debt backlogs?

Inspect and Adapt During Sprints

When a sprint starts, the work may not be well understood. The team learns along the way and should update the acceptance criteria as needed and communicate the changes. Sometimes, an acceptance criteria may emerge or even be dropped depending on if the work is still valuable in a smaller form or if discovery reveals the work as described cannot be completed in the sprint and how this work relates to the sprint goal.