Product Owner (PO) role is a very important role in Agile. She often wears many hats! She is working with Stakeholders on creating and maintaining the Value Backlog and identifying the right priorities.  She is also working with the Development Team on creating Work Backlog that creates the Value that is being sought. She is essentially working as a bridge between Stakeholders and the Team, between Value Backlog and the Work Backlog. And she is acting as a bridge between the Business and the IT.

The Product Owner also sets the direction of the Initiative (or Project, if you want to call it that). She sets the direction by identifying the priorities; and she is one of the big factors, if not the only factor, that has huge influence on success or failure of the initiative.

Benefits of Standard Work
Product Owner role being such a critical role in the success of your initiative, would it help to document the work she has to do? Does it add value to having documented this Standard Work?

[callout]Standardized work is one of the most powerful but least used Lean tools. By documenting the current practices, standardized work forms the baseline for continuous improvement. [/callout]

Let’s review some of the benefits quickly:

• Creating standard / Standardizes the work across different teams, different people; ensuring consistency across the organization
• Set expectations, certain level of expectations, branding as to what’s ‘given’ when the team/individual says a certain task is done
• Sets up a common platform against which the effectiveness of the individuals can be measured
• Ensure certain level of quality
• Ensure that certain routine, mundane tasks get done (and don’t get overlooked due to them being ‘boring’)

Standard Work: Product Owner
Let’s start identifying the activities for the Product Owner now that we are clear on the importance of the role and the benefits of Standard Work. We can start listing out the Daily and Weekly activities, as well as the activities that need to happen when a specific event is happening, for example, Release Planning.

[tabby title=”Daily”]

• Attend the Daily Scrum meeting
• Did I answer (if any) questions raised by the Team members, within a few hours?
• Did I resolve / remove / find work around for business impediments?
• Do I need to provide Story-level CAT (client acceptance testing)?
• Do I need to connect with business Subject Matter Experts / business community for any open or upcoming item?
• Story Burnup
  • Did I update and review Story Burn up chart?
  • Is the team working on highest priority stories?

[tabby title=”Weekly”]

• Product Backlog planning / Backlog grooming with Business stakeholders
• Break Epics to Features, assign Business Value
• Break features to potential User Stories
• Ensure that each Story has “Who, What, Why” identified
• Ensure all Features and User Stories have Acceptance Criteria (AC)

[tabby title=”For Each Sprint”]

• Review charts
  • Release Burn up / story completion
    Examine the “top line” scope, the current and projected velocity, and the anticipated date the velocity line intersects the “top line” scope. Make adjustments to scope or release date as necessary
  • Feature completion
    Is the team working on right things in the right sequence? Is effort being applied to future features that should be applied to near-term features?
  • Business value completion
    Examine the trend of business value per story point (RoI) being delivered. Can we sequence higher ROI features earlier in the release schedule? If only lower ROI features remain, can we end the project early? Can we remove high-cost / low return stories from features to improve the feature ROI?
  • Maintain Product Backlog
    • Re-sequence features
      Examine the planned features for each release and adjust as team velocity, capacity, ROI, risk, dependencies, etc. are better understood
    • Create/Update/Delete Epics, Features and User Stories
      As we get smarter, update the backlog with the current understanding of the epics/features/stories
    • Backlog Grooming with Team
      Work with the Team to add sizes to any epics/features/stories that don’t have a size assigned
      Ensure information dashboards are updated and visible (topline, velocity, release burnup)
      Assess risks and dependencies among epics/features/stories
  • Get Ready for next Sprint Planning meeting
    • Collect highest-priority stories that represent approximately 125% of the teams average sprint velocity.
    • Ensure user stories are detailed enough with validations for team commitment.
    • Work with the technical Product Owner (tPO) to identify and prioritize the highest-priority/predecessor enabling (technical) stories
    • Develop and communicate Sprint Goal(s)
  • Sprint Review
    Facilitate part of the review, explaining Business Scenario and Goals, and then hand-over to Team member to showcase/demo the functionality
  • Participate in the Sprint Retrospective with the Team
  • Sprint Planning
    discuss the sprint commitment with the team. Hold the team responsible for meeting that commitment.
  • Update Vision (if necessary)
  • Communicate sprint/release progress to stakeholders

[tabby title=”For Each Release”]

• Create/Update the Vision
• Identify epics and features
• Assign business value to epics and features
• Group features into “minimal releasable feature sets”

[tabbyending]

Would it help to have your standard work documented? Can it help you, your team improve the productivity and deliver more VALUE for your customer?

Go ahead and document your Standard of Work. Start with this list, update it, refine it, and put your team on the “hyper Productivity” lane!