Product Owner and Scrum Product Ownership
Product Owner and Scrum Product Ownership
In Scrum, you need a product owner, but it's more than just filling a role. What does it take to be a successful and efficient product owner?
Join the DZone community and get the full member experience.Join For Free
Who Should Play the Role of Product Owner?
In Scrum, you need a Product Owner. But it obviously takes more than just filling the role. The effectiveness of that role and of the overall Scrum implementation depends a lot on the type of person in that role
The Product Owner is someone who guides product direction via the backlog and works with both end-users and the Scrum Team to ensure that the highest value features are always being developed first and released.
The Product Owner represents the customer to the development team in terms of conveying what they want, why they want it, and how that translates into a technical deliverable. The product owner will work with the customer to define features and requirements as completely and simply as possible and set priority. When the team asks questions about how the requirement should work, the product owner provides the answers. Above all, the product owner not only defines product vision but they maintain and convey it to the team and organization. The product owner works with the market, stakeholders, and experts to ensure the product is going in the right direction and providing value to end-users. They're responsible for maximizing the value of the product by keeping on top of the backlog, ensuring that it contains all priority features and well-defined stories that are ready for the team to action.
Product Owner Competencies
- Expert in the domain and have a thorough understanding of the product value
- Strong communication and negotiation skills to figure out what users need, and then work with the Scrum team to see what they can deliver
- Ability to translate customer or business needs into technical requirements
Product Owner Responsibilities
- Capture, manage, groom, and prioritize features, requirements, and break those down into stories for the development team
- Decompose requirements into simple elements that can be delivered in a sprint
- Ensure the acceptance criteria of the story has been described and the definition of done is fully stated
- Work closely with the development team to describe all stories
- Ensures that the right customer problem is being solved
Product Owner Qualities
- Possess experience and knowledge to differentiate between what the client needs
- With a keen understanding of the business needs, the product owner will prioritize these items first to deliver the most value
- Communicate effectively with both the business and technical stakeholders. They use the input from these groups to refine and prioritize the backlog to set product strategy and direction
- Ensure that the backlog is always prioritized with the most valuable work at the top broken down for the next sprint
Scrum Product Ownership
Product Owner is responsible for the product backlog, decomposing features into workable complete user stories, setting iteration goals, and working directly with the Scrum team to produce a shippable increment of the product with each sprint. The development team is a cross-functional, multi-disciplinary team, who can complete the work and build solutions to deliver a releasable increment of the product.
They interact with customers to understand their needs and hear how they use or want to use the product. The development team will determine the complexity of stories in the backlog and set the capacity for how much work they can accomplish in each sprint. The Scrum Master is responsible for ensuring that the team follows the process, stays on track, and focuses on their roles. The Scrum master will coach the team throughout the Sprint events and help the teamwork as efficiently and effectively as possible. They'll remind the product owner to focus on product vision, and the development team to focus on solutions. They'll track and post velocity so the team can see at a glance how they're progressing in the Sprint.
While the product owner has an overall strategy and roadmap for the product, the team is responsible to deliver the value and create a release for the market. The product owner should help the team see the bigger picture by explaining the vision, engaging with the team and stakeholders, and providing clarity on why features are needed and how they'll be used. And to ensure that functionality will properly flow and integrate, the product owner needs to involve the team in product design. The product owner should leverage the team's expertise to review the backlog and storyboard flows to help ensure consistency, product understanding, and integrity and to boost creativity within the team.
Defining Product Requirements
We're going to look at different tools and techniques that teams and product owners can use to generate product ideas:
Product Vision Board
The product vision board guides the team in defining the product. At the top of the vision board is a vision statement. At a high level, what is the product? This should be a short description that is very clear and concise. You may want to write this as a team after answering the below questions:
- Who is the target group of users for the product?
- Who they believe would be the primary users, who might be secondary users?
- Which market segments the product could hit?
- What customer or user needs does the product solve or provide a solution for?
- What is the major value that will be delivered by the product for the end-user?
- What are the top features that will be delivered?
- What allows the product to really stand out from others in the market?
What is the value to the organization?
How will the product roadmap benefit the company in the long and short term?
Dot voting is a quick and efficient way to roughly estimate a small number of requirements or discuss ideas to help a team choose an option when there are multiple good options on the table.
- Each team member is given a number of sticky dots, requirements, options, or ideas are posted on a board
- The facilitator may quickly walk through the options to give the team context
- Team members will then place dots on requirements or ideas that they believe require more effort or on the option they think is best
- Requirement with more dots will have a higher story point value than those with fewer dots or options with more dots would have the majority of preference and give the team direction
Dot voting is a useful method for selecting multiple items to work on. And can quickly give the team a sense of overall perception, thoughts on complexity, or preferred options for direction.
This is a really quick method to gauge the team's opinion on a topic that needs a yes or no answer. The facilitator will present the topic and decision point and the team could discuss the pros, cons, and options. The facilitator will need to be careful to frame the question so that a yes or no answer applies.
Once the topic is understood and framed, all team members will vote using their thumbs. Thumbs up indicate Yes. Thumbs down is a No and a sideways thumb means the person doesn't know, is unsure, or doesn't really have an opinion.
Depending on how critical the decision, the team may need to spend more time discussing the topic at hand. And allow the team members to come to a more informed opinion. In some cases not having an opinion on a topic might be okay. You'll need to assess each situation on its own. This method should really only be used when there are two options, or a clear yes/no response can be given.
Fists of Five Voting
This is an easy way to simulate a scale from one to five, where the team simply uses their hand to cast their vote. Fists of five voting can be useful to gauge a range of agreement, where the team may agree on a topic, but to various extents. This is a great way to allow for nuances and for the team to express their opinions more discreetly.
The product owner or facilitator will explain the topic that needs direction, collaboration, or consensus. And the team will vote by holding up the number of fingers corresponding to their level of agreement.
The number of fingers held up indicates the level of support by the individual.
- 5 indicates that the person thinks the idea or direction is amazing or exceptional. What a great idea.
- 4 indicates full support. This is definitely the direction we should take.
- 3 indicates team member is on the fence, neutral, or unsure. Maybe more discussion is required to convince the person either way.
- 2 indicates that the team member thinks it's a bad approach and that the team shouldn't pursue it.
- 1 is basically saying, no way. It may be too risky or a bad direction for the project team.
Product owners are the secret stars of Agile software development, driving sprints in a Scrum cycle to meet both stakeholders’ and customers’ needs. To stay on top of this continuously evolving process and changing market dynamics, product owners need strategic approaches & powerful tools where they can track progress, input, metrics, and more and maximize their development efforts.
Published at DZone with permission of Ketan Vegad . See the original article here.
Opinions expressed by DZone contributors are their own.