Assess and improve your product owner’s skills. This checklist contains key points that you need as a product owner to maximize the effectiveness of your scrum team. Consider this list as a reminder of the best practices.
- I know the purpose and motivation of creating the product
I understand and can explain why the product should be developed. There is a written document that describes the reasons for why this product should exist. The team is aware of and shares the vision as well.
- I know the value of the product to the customers
There is a defined customer segment that the product caters to. I know what type of customers are interested in it.
At least, there are some clear assumptions regarding target users. The product has clear and defined values that it creates for specific people. The value proposition has been written down as well.
- I can answer questions about the product business model
Whenever someone inside or outside the team asks about the business model, I can give a concise and motivating answer immediately.
- I can express the essence of the product in one short sentence. E.g. “One powerful phone” of iPhone 6S
I have all the information needed to explain what it does and why in a short sentence. It is clean and easy to understand.
- I appreciate the needs of the stakeholders
I know and understand key priorities and requirements of all of my stakeholders. I communicate with them regularly to keep them updated on this.
- I know my stakeholders
There is a clear understanding of who the stakeholders are. I know many of them personally.
- I maintain a backlog considering stakeholders’ interests
I can answer questions about product backlog and expand on how each backlog item will benefit and create value for stakeholders.
- Stakeholders trust me
My stakeholders appreciate my work as a product owner and are willing to help me. They believe in me, and I can speak to them openly.
- My stakeholders know current release plan
I keep my stakeholders up to date about the development schedule, and my forecasts are based on the team’s current velocity. All the stakeholders have some access to the backlog information, estimates and so on.
- I have a clear product backlog
Features I’m considering adding to the product are outlined and described well. I can add more items to the product development roadmap anytime. I can easily access the backlog to make edits.
- Backlog items are prioritized
My backlog is ordered. Elements in it are structured and organized by priority, estimates, risks, value, etc.
- I keep Backlog clean
I continually review my backlog to make sure there are no obsolete items. I periodically clean up legacy items that I am not interested in anymore.
- I update backlog frequently
I have the right to make decisions about it. I revisit it at least once per sprint before each planning meeting. It is fresh and up to date.
- Product backlog is visible to the team
Anyone in the scrum team can access it anytime.
- I protect the team from anyone who tries to amend the sprint
I know the importance of keeping sprint’s backlog items unchanged during the sprint. I do everything I can to make sure this rule isn’t breaking.
- There is only one product owner who makes decisions
My team has only one product owner who defines backlog items and refines sprints. Thus developers know precisely who to listen.
- I trust my scrum team
I know what my team can do and trust team’s capabilities.
- I share my vision with the team
I am available to my team. I have time to speak with developers during the sprint to answer their’s questions and clarify requirements.
- My team and I have a definition of done
We share the understanding of the acceptance criteria. They know how the work will be verified.
- I participate in sprint planning meetings
I schedule a sprint planning event with my team where we select backlog items for the next sprint.
- I participate in demo meetings
After each sprint, I and my team schedule a meeting where we review what has been done, gather feedback and check whether the acceptance criteria were met.
- I participate in retrospective meetings
We continuously hold a retrospective meeting after each sprint to understand what went well, what didn’t, and what we can improve going forward.
- I communicate with developers on a daily basis
I am available during scrum meetings or at least later in a day to help them.
- I schedule events with scrum master
I have a calendar with the events scheduled with the scrum master.
- I keep communication between departments and teams
I make sure that the development team can communicate with marketing, sales, support, and others to share the product vision. Occasionally, we have inter-team meetings with representatives.
- My teams have a common goal
Departments and teams serve the same purpose and help each other.
- I know the roles of everyone in the organization
Role of every person in the organization is defined and clear. Everyone knows who is responsible for what.
PDF version for print
PDF is available for download here. This page is also optimized for printing purposes so you can simply print it out.