Scrum Product Owner - All you need to know.

Introduction

A product owner (PO) is a role that is played by a individual within a scrum team and is often confused with the job title product manager. Some organizations hire both PO's and Product managers (Where its likely the PO will report tot he Product manager) while others will have the Product manager play the role of a PO. In short a Product Manager will have more responsibility that a PO. So lets have a look at the scrum role that is known as the product owner.

Responsibilities

Its the POs job to understand the product that is being built and guide its feature development several months into the future. To do this, the PO must understand the requirements as the customer wants it and translate it into User stories that the dev team will understand. In other words the PO represents the customer within the scrum team. Below are some of the typical responsibilities of a PO.

• Backlog grooming (Managing the backlog) - The backlog is a project artifact that contains a list of items that depict what features a product will have in future. It's the PO's responsibility to ensure that this backlog is up to date, relevant, understandable and prioritized (backlog prioritization). Tools such as JIRA and MS project are used for this purpose. There are 2 types of backlogs: The product backlog which contains features to be implemented by the product in future and the sprint backlog which contains items that are to be implemented within the sprint.

Image 1: Example of a sprint backlog vs a product backlog

• Managing the product roadmap - The product roadmap is a high level project artifact that showcases what direction your product will take in the near future. It helps plan the product and aligns the organizations short term and long term plans with respect to the product.

Image 2: Example of a product roadmap

• Stakeholder management - This is perhaps the most important responsibility and includes managing expectations, translating requirements and managing priorities between key stakeholders such as the Customer, the scrum dev team, the Scrum master and in some cases the project manager.

Apart from these key responsibilities the PO is also expected to be a Subject Matter expert, hence he or she will be the go-to person when someone has a question on the product features. The PO is also expected (with the help of the scrum master) to drive development and to ensure that the dev team is on the right track. Dependency management of backlog items is a another task of the PO. As the product adds more features and gets more complex, its the PO's duty to ensure that the links between these features are identified and managed. Sprint velocity is the amount of story points a team covers during a sprint and is a measure of work completed. Project velocity is the same but covered over larger period (multiple sprints). Overseeing project velocity is another task for the PO. The PO must ensure that the teams velocity is not too high and not too low. Being responsible for ROI is an optional responsibility that is often forgotten. If the client provided financial details it may be expected from the PO to calculate and be accountable for the ROI of a given feature i.e How much did the customer earn from that feature vs how much did he spend. And finally Managing product related risks is expected from the PO. Are we building the right thing? Will it be used by the right people? Whats the tradeoff? Does this feature add value? are but some questions related to risk that the PO must manage.

Image 3: Example project velocity chart: 1) Estimation statistics, 2) Value committed to sprint 3) actual sprint velocity, 4) Sprints.

Challenges of being a PO

Every role in scrum has its own set of challenges and its no different for a PO. Here are some of the common challenges a PO must face on a regular basis.

• Not having clear objectives for the project - Dealing with ambiguous requirements is part and parcel of being a PO, but some customers take it to an extreme level. Its not uncommon for customers to ask a team to work on a project with no clear goal in mind. This makes planning the roadmap and sprints difficult for POs.
• Stakeholders that are too agreeable or too resistant - As a PO you are expected to negotiate many things with stakeholders such as Customers, the dev team and the scrum master. When these stakeholders say YES to everything or on the other hand say NO to everything, it severely impacts the growth of the project. If yours is the only opinion that matters (or doesn't matter) in a project it causes a cascade of problems that are difficult to recover from. This is where people skills come in useful for a PO. You have to use these skills to hit up a balance between your stakeholders that is good for the project.
• Managing change requests during an active sprint - In a ideal world once a sprint begins the sprint backlog is frozen for its duration. But in the real world you'll have customers asking you to make a few changes during the sprint once in a while. This is a difficult but sometimes necessary task and the decision to cater this change should be taken case by case. On one hand if the change delivers a higher value shouldn't it be catered on the other hand it will impact the natural way the team does work and may introduce bugs. A good scrum team aims for a balance between Agility ( Ability to adapt new changes) and Flow ( Sticking to the sprint plan)
• Saying no to the customer - Sometimes customers come up with unrealistic requests and the only thing you can do as a PO is to just say NO. But this is easier said than done, because the customer is the king ( and they fund the project ) and you do not want to be on their bad side. Overcome this challenge by using your people skills to explain to the customer that the change or feature they requested is just not going to happen.
• Prioritizing user stories - This is a key responsibility of a PO and perhaps one of the most difficult tasks. As a PO you must understand the tradeoff between features, do you get the team working on a long term feature that adds great value to the product or a short term bug fix that's been pestering the end users for some time? You must also decide on what not to build ! You'll get many ideas and requests and feedback from various channels on the outlook of your product, but its up to the PO to decide which to consider and which not to. You can use models such as the MoSCoW model (explained later) to help you with this.

Doing the actual work - Discussing requirements with customers

It is the POs job to talk to the customer (or project owner) and get the requirements. These can come in the form of a informal chat or a detailed specification. Regardless its good to have a iterative process in place to capture, understand and verify requirements from the customer.

Doing the actual work - backlog grooming

One of the first tasks a PO must undergo in scrum is backlog grooming, where the user stories are written and then prioritized. A user story is a single unit of work that a team must develop during a sprint. The PO must create user stories based on the input from the customer as well as their own expertise. A good user story follows the INVEST principals such that they should be

• Independent - User stories should be independent as possible. If they depend on each other it may cause problems in planning and prioritization.
• Negotiable - User stories should not be rigid with explicit details on how it should be done. It should be open to conversation and change
• Valuable - If the story does not provide sufficient value to the product and customer it may not be useful at all. POs may assign story values to gauge which stories are more valuable and use this to prioritize user stories.
• Estimable - Story point estimation is a vital part of the scrum process. It is done at the Sprint planning meeting and is a important input for checking the velocity of the team. If the story is written in a manner which is difficult to estimate then it impacts the whole planning process.
• Small - This is a no brainier. User stories by definition should only be 2-3 lines at max. Any more and they should be sliced into smaller ones.
• Testable - The dev team need clear and concise details which tell them how this story is considered complete. These conditions for completion are called success criteria and its creation is the responsibility of the PO. Ambiguous criteria such as the story should be bug free should be avoided at all costs.

Its also good to remember the 3Cs when writing user stories.

• Card - Stories are written on note cards (Digital or otherwise) with a short but clear explanation. They can be annotated with extra details.
• Conversation - User stories should encourage conversation between key stakeholders
• Confirmation - Acceptance criteria confirm the conditions under which the story is considered completed.

Things to look at when writing user stories

There are a few common things you should always look into when writing user stories. Here are some of them.

• Who is the audience ? - In other words who is the target market of your user story ? You should also remember not to remove certain segments based on lack of judgement. For example if you are designing a ATM for visually impaired will you ignore those who have good vision ? And remember to focus on the real segment. Say you are designing a refrigerator for kids but its the parents who will be doing the actual purchasing.
• How does the feature add value ? - Ask your self What does the feature solve and how does it do it? This will help you understand how important the feature is for both the customer and the end user.
• Whats the tradeoff ? - Selecting one user story over the other will always have a tradeoff. Do you implement that simple feature that can be done in a couple of sprints or do you work on a epic that adds a lot of value but will take more time ?
• Whats the risk ? - What are the Financial, Technical and Social risks ? Will the feature be too expensive? Does the team have the expertise do complete it ? and will the end users see value in it? Are some questions you should ask.

Writing the stories

The standard template for writing a user story follows the who, what, why principal. The standard template is As a <WHO>, I want to do <WHAT>, so that I can <WHY>. Here's an example: As a manager I would like to see hours worked in by all my employees so that I can use this data for analysis

Adding details to user stories - DOD (Definition of done) vs DOR (Definition of ready) vs Acceptance criteria

Those who are new to being POs often ask; If user stories are meant to short and sweet where do we add the finer details? And the answer is using acceptance criteria, which you can think of as a checklist that each user story must pass in order for it to be completed. The next question I get asked is then what is the Definition of done (DOD) ? DOD is similar to acceptance criteria but is common for all user stories. The items in the DOD is discussed usually during the project start and is agreed on by PO, dev team, Scrum master and sometimes even the customer. While the acceptance criteria is written for each user story and is owned by the PO and agreed by all during sprint planning. Furthermore the PO does not check if the DOD is implemented or not that's the whole teams responsibility. What he does have to check is that if the acceptance criteria for the story has been implemented or not (Done during the sprint review)

So whats the Definition of ready (DOR) ? The DOR is similar to the DOD but it is a list of items that are to be checked by the PO to ensure that the story it self is upto standard. This list is universal to all stories and is set up usually during project inception.

Its vital to note that both the DOD and DOR are not rigid and that it should be changed if the team feels it doesn't add value.

Here is an example of 2 user stories with their DOD, DOR and acceptance criteria.

Image 4: Example user stories with acceptance criteria, DOD, and DOR

Note that while the acceptance criteria has changed the DOD and DOR have not. In summary the DOR is a checklist that the PO checks to ensure that the user story is ready to be worked on, while the DOD is a checklist that must be completed ( mostly by the dev team) to ensure that the user story is ready for review. And finally the acceptance criteria is a set of items to be checked by the PO to ensure that the user story conforms to the requirements.

The benefit of acceptance criteria is that is forces the team to think from the users perspective, and helps remove ambiguity

User story mapping

User story mapping a visual technique used for mapping user stories with user activities and product releases. The first step is to identify what actions a user will take for a given epic. Then for each action map out the user stories that complete this action. You can add additoinal layers by planning on which releases or sprints the stories will be implemented.

Image 5: Example user-story mapping

Doing the actual work - backlog prioritization

Now that the stories have been defined the next step is to prioritize them. The objective is to look at each story and identify how much value each story adds to the customer or product. Each individual stories importance can be described as a number of increasing priority such as the Fibonacci sequence (1,2,3,5,8) or power of 2 (1,2,4,8,16) or it can simply have a label showing its priority.

A model that can be used to gauge user story importance is the MoSCoW model. Must Have is the highest priority and is a user story that are absolutely needed. Should Haves are the stories that add great value but are not necessarily vital. Could Haves items are nice to have but have little impact if not implemented. Wont Haves are the stories who don't add any significant value at this point.

Remember that while the PO is responsible for backlog prioritization he or she should discuss the priorities and come to an agreement on them with the rest of the stakeholders.

NOTE: backlog prioritization is a sub task of backlog grooming. backlog slicing is also a sub task of backlog grooming and is the process of breaking large stories into smaller ones.

Doing the actual work - sprint planning

So now we have a list of items in the backlog that are well defined and prioritized. The next step is to plan a few sprints into the future and is done during sprint planning. This meeting is conducted prior to sprint start. Participants include the PO, Scrum master dev team and optionally the customer. The objective is to decide what items to work on during the (next few) sprints and prioritize them. The output is the sprint backlog (see image 1) which is the list of prioritized items that the dev team will work on during the sprint.

Before the team selects which items to work on they must estimate them and assign story points to each story. Just as for Story values (discussed earlier) the team and assign a number of increasing priority such as the Fibonacci sequence (1,2,3,5,8) or power of 2 (1,2,4,8,16).

Scrum poker is one method to assign story points, where each team understands the story independently and estimates its story points. If one or more members have different values then the story should be discussed again to identify and reason on its point value. Its important to remember that if members have different values you should not average the point value but instead discuss the reasons for the difference. The whole point of scrum poker is to facilitate discussion rather than come to a consensus quickly. You should also note that Story points should not be used as a substitute for effort. In fact Story points are meant to be a estimate of complexity not an estimate of effort.

Once the story points are assigned the next step is to do the actual planning. This involves selecting items from the product backlog and assigning them to the next sprint ( and maybe a couple more future sprints). So how do you know much story points your team can complete in a sprint AKA sprint velocity ? If your scrum team is new then you would not know what its velocity is and you'll need to go though several sprint iterations to come up with a acceptable velocity. Keep in mind that as your team progresses through multiple sprints its acceptable velocity should be looked at and updated. This is done though the velocity breakdown chart ( refer image 3 above) and is the responsibility of the PO. As a PO its your job to make sure the team works on the right amount of Story points per sprint. If the velocity is too high it may mean that the team is burdened with work, too low would mean that the team is underutilized.

When all stakeholders agree on the items for the current sprint, it can be started. A sprint usually lasts 1 or 2 weeks depending on the team.

NOTE: The scrum teams estimating ability (Both story value and story points) increases as the team matures. Hence you should not be too worried about getting it right at the beginning.

Doing the actual work - daily standup (daily scrum)

Once the sprint starts the team will have daily standup to discuss what they did during the last day, what they plan on doing and what issues they face. The standup is facilitated by the scrum master but the PO should attend it to clarify any uncertainties or issues related to the stories. The daily stand up is a quick meeting and should not exceed 15 mins.

Doing the actual work - Defining the developer tasks

Its the dev leads responsibility to discuss with the team and breakdown user stories into tasks that should be done by the team. The PO does not need to but depending on your organization may be asked to join these meetings to provide additional input.

Doing the actual work - Sprint review

When the sprint completes the team will demo what they have done during the sprint review. It is during this session that the PO must check the both the DOD and acceptance criteria of the story and verify if the story is complete or if it needs rework. Partially completed work should not be accepted as this would distort the teams velocity. The sprint review is owned by the PO and its vital for them to provide honest feedback on each of the items.

Doing the actual work - Sprint retrospect

This takes place after the sprint review and before sprint planning. Its usually facilitated by the scrum master and its objective is to discuss the details of the last sprint such as what the team did right, what the team did wrong and what should be changed. There is no hard and fast rule on what needs to be discussed here or what questions the team should ask it self but the purpose is to learn and adapt from the last sprint.

Doing the actual work - Planning the product roadmap

The product roadmap is a document that shows the planned status of your product over a period of time. In other words its a high level summary of intended direction your product should take. It will describe what is being build and why its being build not how to build it. This should be build with inputs from the all key stakeholders and should be updated as more information is made available.

Image 6: Example product roadmap

KPI's to measure a POs performance

It might seem difficult to measure a POs performance as most of the work they do seem subjective rather than objective. But there are a few KPIs that a organization can look into when evaluating performance.

• Defects referred to next sprint - This is a measure to identify the number of surprises during a sprint. A large count may indicate that the stories written are not good (i.e written from multiple viewpoints, doesn't contain enough details and may be too complex)
• Issues reported x days after production - A good product owner will ensure that his team clearly understands the requirements by providing constant and valuable feedback about the stories. The period checked is usually about 30 days but can change per organization.
• Value returned per effort - This is linked to a teams velocity and is a measure of how much value the team returned per one unit of effort. Constant and proper backlog grooming will help the PO maintain this at a high level.

In short the number defects reported, number of stories rejected, the teams overall velocity and the POs availability are good measurements to check when evaluating a POs performance.

Advice for new POs

If you are new to the role of PO here are some advice to help you adapt to your new role.

• Learning to deal with ambiguity - Like me, if you came from a Software engineering track then you would love clear and well understood requirements. Unfortunately in the line of a POs work that may be luxury that you must avoid. In most cases the requirements from the customer may be ambiguous and you will have to go though several rounds of discussions to finally understand what they want.
• Learning to say NO - As important as it is to decide what features to add, its also important to know what not to. Remember as a PO you represent the customers voice but it doesn't mean you should execute their every command. As a PO you must provide valid reasons on why you reject certain stories.
• Learn to rationalize - Its easy to just use your expert judgement to do your work as a PO but it will hurt you in the long run. Different stakeholders will have different opinions on whats right and wrong. So its up to you to use logical, rational and meaningful explanations on the decisions you make.
• Learn to manage your effort - Depending on the organization you may be asked to act as the PO for multiple projects / products. Needles to say you'll need to juggle between doing multiple tasks with multiple stakeholders. So its important to have a good gauge on what you have done and what you need to do in future.

Skills needed for a good PO

Listing, Negotiating , Explaining, Leadership, Documentation, Critical thinking.