In our previous articles on Scrum we talked about what Scrum means and what are the main elements that define it. In this article we will focus on the Product Owner’s role.
The Product Owner usually represents a group of people. He/she is the voice of the client. The PO takes the inputs on what the product should be and translates them into a product vision and a Product Backlog.
Agile Manifesto
In the Agile Manifesto two of the principles refer to:
Customer collaboration over contract negotiation
Responding to change while following a plan
These principles focus on the facts that:
- our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
- we welcome changing requirements, event at later development stages. Agile processes harness change for the customer’s competitive advantage, so we maximize the value in the project.
- there is an internal learning loop, so we deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
- the PO is a team member, so business people and developers must work together daily throughout the project.
Responsibilities
The main responsibilities of a PO are:
- To continuously update the product backlog items in order to have on top of it the most important user stories.
- Represents the business interests within the team
- Responsible for product backlog throughout the project: 1) Vision, scope, prioritisation, release planning and backlog item quality, 2) Ensures backlog items are ready for sprint planning
- Focal point for stakeholders: Active engagement and management of stakeholders
- Responsible for the value of the product (ROI): Building and operating
- Accepts or rejects work results
- Participation essential in product backlog refinement/ grooming, sprint planning, sprint reviews
- Encourage to participate in retrospective and daily scrums
- The success of the team is influenced by the availability of the PO
The essential qualities of a PO are:
Authority: the PO should be the authority in the project. He/ she decides the release dates, the requirements and also accepts or not the work results.
Time: the PO should always be available for the team
Knowledge: the PO should have a thorough knowledge of the market and the competition and also he/she must decide what brings more value to the product.
Product Vision
The product vision is a very important aspect and it should capture and communicate the essence of the product in a concise manner and also be a shared goal that provides direction but broad enough to facilitate creativity
In order to define why we want to develop a product we should start with the desired outcome
Who’s going to buy, use and be impacted by this?
What issues and challenges need to be solved?
What must change in order to succeed?
How will we know if we have succeeded?
How do we beat the competition?
What strategic drivers are there?
When – critical timeframes?
There are different techniques used for visioning:
Impact Mapping
Value Stream Mapping
Prototypes and mock-ups
Personas and scenarios
Elevator statements
Opportunity/ Lean canvas, Product Vision Board
Storytelling (Stephen Denning)
Impact Mapping
Is a strategic planning technique used to build products and to help organisations to synchronize their activities with the business objectives in order to make better roadmap decisions. This method facilitates collaboration and interaction and it allows the participation of people with different backgrounds helping organisations use the wisdom of crowds.
The Impact Mapping technique actually contains the answers to 4 main questions:
Why? – this question is focusing on the goal of the product | Why are we doing this?
Who? – at this level we decide who are the people involved, the actors | Who can produce the desired effect? Who can obstruct it? Who are the consumers or users of our product? Who will be impacted by it?
How? – the impact that we want to create | How should our actors’ behaviour change? How can they help us to achieve the goal? How can they obstruct or prevent us from succeeding?
What? – we decide on the deliverables which are the software features | What can we do, as an organisation or a delivery team, to support the required impacts?
Image source: https://www.impactmapping.org/drawing.html
Product Vision Board
The Product Vision Board technique is used by the organisations in order to describe, visualise and validate the product vision and the strategy of it. This method focuses on the target group, users’ needs and the key features of the product, while keeping all of these aligned with the business goals.
The extended version of this technique also describes other elements relevant to the business, like: competition, channels, cost factors, and risks.
The Elevator Pitch Template
This method is a good way to organise our ideas in order to clarify them and to define what makes our product a successful solution.
Product Backlog Fundamentals
The main responsibility of the PO is to create the PB as an ordered list of functional and nonfunctional requirements that might be needed in the product. The Backlog should be granular, respect the DEEP principle and be continuously refined.
Detailed Appropriately: the PB should be like an iceberg, the items from the top must be detailed enough to be ready for the next Sprint
Emergent: the PO could change the User Stories, could add new ones or remove them based on the market or other factors
Estimated: the items from the top of the PB should be evaluated by the team in order to estimate the right amount of work
Prioritised: the PBIs will be prioritised based on their business value . A way to decide the priorities could be to use the Impact/Effort Grid.
The PB contains User Stories which can be defined in multiple ways:
- Common form: “As a <user role> I want <goal/objective> so that <reason>.”
- Alternative form: “In order to <reason> as a <user role> I want <goal/objective>.”
In order to add more details to each User Story we could use Acceptance Criteria which is a set of rules used by the testers to create the tests and also by the developers to implement that functionality. A proper and easy way to define an Acceptance Criteria is the BDD format (Behavior Driven Development) which contains 3 key words: Given …. When …. Then….
EXAMPLE:
User Story:
As a user, I can cancel my reservation in case my plans change.
Acceptance Criteria:
Given that the customer is a premium member and it is before the check-in date
When the reservation is cancelled then the room is made available, a confirmation message is sent to the customer by their preferred method and the bookings manager is also notified
The quality of the stories is assessed using the adapted INVEST Model by Bill Wake
Independent: if the stories are dependent then for sure we will have issues with the estimation and prioritisation.
Negotiable: stories are not contracts so it implies that some flexibility will be needed.
Valuable: to users or customers, not developers.
Estimable: because plans are based on User Stories, we need to be able to estimate them.
Sized appropriately: small enough to complete in one Sprint.
Testable: so that we have an easy, binary way of knowing whether a story is finished or not.
Conclusion
The PO has a lot of work to do and its role could determine the project’s success if he/she is always available to team and if he/she acts like a member of the team.
