The Product Owner is responsible for maximizing the value of the product and the work of the Developers. How this is done may vary widely across organizations, Scrum Teams, and individuals. The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Developers performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Developers understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Developers do it. However, the Product Owner remains accountable. The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Developers to work from a different set of requirements, and the Developers aren’t allowed to act on what anyone else says.
Skills of a Product Owner
Choosing a right product owner is crucial for any Scrum Project. Following are some of the characteristics expected from the Product Owner
- Visionary : Product owner should be able to envision the final product.
- Doer : Product owner should also be a doer – that means, he should work with the team to get the final product ready.
- Product Owner should be a Leader and Team Player
- Communicator : The product owner must be an effective communicator and negotiator. The Product Owner is the Voice of the customer and therefore he should communicate customer needs and requirements and bridge the gap between the customer and the team. This may mean saying NO sometimes to the customer.
- Empowered and Committed : The Product owner must have enough authority and the right level of management sponsorship to lead the development effort and to align to stakeholders.
- Available and Qualified : The Product Owner must be available and qualified to do a great job. Being the product owner is usually a full-time job. If the product owner is overworked then the product progress will suffer resulting in a substandard product.
Creating Product Vision
Product Owner creates the Vision for the product. The product vision paints a picture of the future that draws people in. It describes who the customers are, what customers need, and how these needs will be met. It captures the essence of the product – the critical information we must know to develop and launch a winning product. Developing an effective product vision is an important duty of the Product Owner. More details on Product Vision is described in the section on Product Development lifecycle.
Voice of Customer
- As a representative of the customer, the Product Owneris said to be the Voice of Customer as he ensures that the explicit and implicit needs of the customer are translated into user User Stories in the Prioritized Product Backlog and later on used to create project deliverables for the customer.
- The customer who is the person purchasing the product and the user who is the individual using the product determine the success or failure of the product. Only if enough customers buy the product and the users find it beneficial will the product be a success in the marketplace.
- To create a winning product, the product owner, the Scrum master and the team must develop a intimate understanding of the customer and user needs and how these needs can best be met. The best way to do this is to involve customers and users early and continuously in the development process. Asking the customers to provide feedback on prototypes, inviting the customer representatives to sprint review meetings and releasing software early and frequently are great ways to learn from the customers.
- In addition to customers and users, the product owners should involve other stakeholders such as
o representatives from marketing
o Sales representatives
o Service team
- Early and regular involvement of all types of stakeholders is the key. The best forum to get the stakeholders involved would be the Sprint Review Meeting. This meeting allow the representatives to see the product grow, to interact with the Scrum team and to share questions, concerns and ideas.
Initial Product Backlog Creation
Product Owner is responsible for creating an Initial Product Backlog such that there are enough “Ready” items to get started. Scrum doesn’t name the activity for this, but we’ll use the term initial Product Backlog Refinement (initial PBR, IPBR), because it is similar to regular PBR each Sprint.
Typical activities include defining a vision, discovering Product Backlog items, splitting large items, refining items until ready, identifying risks, defining “done”, and estimating.
Initial Product Backlog Refinement (grooming) is done once and only once for a product—when you first transition to Scrum or when you start a new product. Subsequently, refinement is done in regular Product Backlog Refinement (grooming).
Product Owner and Sprint Planning Meeting
In Scrum, the sprint planning meeting is attended by the product owner, ScrumMaster and the entire Scrum team. Outside stakeholders may attend by invitation of the team, although this is rare in most companies.
During the sprint planning meeting, the product owner describes the highest priority features to the team. The team asks enough questions that they can turn a high-level user story of the product backlog into the more detailed tasks of the sprint backlog.
The product owner doesn’t have to describe every item being tracked on the product backlog. A good guideline is for the product owner to come to the sprint planning meeting prepared to talk about two sprint’s worth of product backlog items. To make an example really simple, suppose a team always finishes five product backlog items. Their product owner should enter the meeting prepared to talk about the top 10 priorities.
There are two defined artifacts that result from a sprint planning meeting:
- A sprint goal
- A sprint backlog
A sprint goal is a short, one- or two-sentence, description of what the team plans to achieve during the sprint. It is written collaboratively by the team and the product owner. The following are example sprint goals on an eCommerce application:
- Implement basic shopping cart functionality including add, remove, and update quantities.
- Develop the checkout process: pay for an order, pick shipping, order gift wrapping, etc.
The sprint goal can be used for quick reporting to those outside the sprint. There are always stakeholders who want to know what the team is working on, but who do not need to hear about each product backlog item (user story) in detail. The success of the sprint will later be assessed during the sprint review meeting against the sprint goal, rather than against each specific item selected from the product backlog.
The sprint backlog is the other output of sprint planning. A sprint backlog is a list of the product backlog items the team commits to delivering plus the list of tasks necessary to delivering those product backlog items. Each task on the sprint backlog is also usually estimated.
An important point to reiterate here is that it’s the team that selects how much work they can do in the coming sprint. The product owner does not get to say, “We have four sprints left so you need to do one-fourth of everything I need.” We can hope the team does that much (or more), but it’s up to the team to determine how much they can do in the sprint.
What a Product Owner should NOT do
- A Product owner should not vanish after a sprint planning meeting and then reemerge at the Sprint review meeting. This type of product owner does not have any collaboration with the team. Sometimes the Scrum Master or Team Member then does a proxy product owner role
- A Passive Product Owner is also a bad idea. Product Owner should actively contribute to the Sprint Review and Sprint Planning meeting and ensure that high quality products are delivered to the market.
- Many product owners make the mistake of pressurizing the team to take on more work. They may achieve a higher short-term velocity, but it is not sustainable. As a product owner its important that he respects team’s empowerment no matter how the release burndown looks. If the progress is slow then it is a good idea to get everyone together to search for a creative and healthy solution rather than bully the team.
- Product Owners should not act like a customer during a Sprint Review meeting. The Product owner should accept the deliverables before the Sprint Review meeting. During the Sprint Review meeting, the Product owner should be on the side of the team presenting the product to the stakeholders to get their buy-in.
- The product owner should not report the Sprint Burndown to the Senior Management as a status report. The Sprint burndown is for the team to track the progress.
- A Product owner should not be a Distant Product owner. A Distant product owner works separate from the team. If the teams are distributed, the Product Owner should be a travelling ambassador and should spend time with the teams distributed across the globe.
- A Product Owner should not be a Proxy Product Owner. A Proxy Product owner is a person acting on behalf of the product owner and is a placeholder. Generally Proxy Product Owners are used to compensate for overworked, partial and distant roduct owners.
- A Product Owner should not be a committee. That means a group of people without anyone being in charge of the overall product. In a committee, there is no one person guiding the group or no one helping create a common goal or owning up decisions.
Click here to understand how Product Owner role is different from a Business Analyst role.