SCRUM PRODUCT OWNER CHECKLIST

Sean Dunn 10 June 2013 Inspired by Michael James ScrumMaster Checklist www.scrummasterchecklist.org

This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License. for doing well for could be improved and I know how to start ? for could be improved but how?

Is your number one priority to ensure that the backlog is consistently maintained and ready for iteration planning? Do you dedicate enough time each iteration to ensure this happens? Do you respect the utmost importance of your participation in the iteration planning meeting and attend religiously? If you absolutely are unable to attend, is your vision and intent sufficiently passed-off to someone who can capably take your place? Have you developed a consistent, compelling and comprehensive product vision, received stakeholder buy-in, and communicated this vision (repeatedly) to the team? Do you strive to inspire the team and help them feel a sense of purpose and value through the product they are delivering? Do they understand how the work they are doing helps the customer and fits into the overall company strategy? Have you developed a Product Roadmap that extends 2-3 releases out? Do you understand that although this vision is valuable, the plan will inevitably change? Do you collaborate with the team to create the Release Backlog? Do you frequently (at least twice an iteration) exploratory test the software to understand the functionality that the team is working on and provide them feedback? Do you have a good working relationship with the ScrumMaster and converse daily? Is the ScrumMaster free and comfortable to correct you when your words or actions are not consistent with Agile values or practices or are an impediment to the team? Are you available to answer questions from the team, ideally within half-an-hour?

 Do you focus on the what but not the how? Do you abstain from interfering with technical decisions, but rather letting the team have the freedom to make those decisions themselves? Do you know who your various stakeholders are and spend the majority of your time communicating with them? To the team, are you ultimate authority for deciding on prioritization? To them, your vision is the one true vision. Do you work with the team to help them understand the perceptual quality expectations for the product? Do you trust the team to deliver a quality product in alignment with your vision? Does the team have a definition of done and are you aware and comfortable with it? Do you have a working agreement with the team that outlines your roles and responsibilities, as well as theirs, and do they feel free to hold you accountable when you do not follow this agreement? Are you available to validate & accept User Stories as the team completes them, ideally within a day of the work being completed? Do you work with the team to help them understand the expectations for User Experience in the software and the right balance of form vs function so that they can make more and more decision on their own? Do your User Stories have acceptance criteria defined before the team undertakes the work? At least once an iteration, do you ensure that the most recent iteration of your product is demonstrated to the various stakeholders, and do you solicit their feedback and incorporate it into the release plan? Are you engaged in the planning meeting and collaborate with the team and actively negotiate User Stories with them? Do you have a definition of ready so that you know when User Stories on the backlog are ready to be pulled into an iteration plan? Is the backlog a manageable size? Are items closer to the top of the backlog more granular, and the ones further in the future larger? Do User Stories on the backlog satisfy the criteria of Independent, Negotiable, Valuable, Appropriately Sized, Estimable, and Testable? Do you enable an environment of sustainable development where the team is able to work at a consistent pace indefinitely?

 Do you remind the team of the importance of business value and resist attempts by the development team to split User Stories along technical lines or create User Stories for refactoring? Do you understanding the Lean principle of minimizing waste, and strive to minimize waste in your own practices, including framing discussions in terms of business value, eliminating lowvalue meetings, documentation and activities, etc? Do you understand the Lean principle of minimizing Work-In-Progress (WIP) and strive to limit the amount of organizational multi-tasking? Do you understand the Lean principle that delays induce work and strive to minimize delays in the process, including delays in feedback? Do you frequently review the Burn Down / Burn Up chart to see how the team is doing on completing the scope? When the scope will not be completed in time, do you either work with stakeholders to adjust the release date, or cut the lowest-value scope from the release? Do you frequently adjust the Release Plan after higher-priority work becomes apparent and adjustments need to be made based on stakeholder feedback? Do you give the team positive feedback when your stakeholders are excited about the work they are doing? Do you express your disappointment when the team is unable to deliver on commitments? Do you support a continuously learning organization and work with the team to continuously improve how you communicate and interact with them? Is your backlog an information radiator, clearly visible to all stakeholders? For stakeholders that are not co-located, do you actively share the backlog with them? Are you an Agile ambassador to stakeholders and management, actively promoting the benefits of Agile to them? Do you understand and support the long-term technical vision of the team to be more agile and give them the freedom to invest in improving their engineering practices? Do you understand what Technical Debt is and how to avoid it? If you're using an automated tool for backlog management, is it actually working for you?

Do you take opportunities to be a teacher of the domain to the team, always helping them to advance their knowledge of the domain, helping them to understand the problem space rather than dictating the solution?