Best practices for Product Owner to use Quickscrum

Home Best Practices Product Owner

The product owner (PO) is a member of the development team responsible for defining the user stories and prioritizing them in order to deliver the most valuable business needs faster to the end users. The product owner must be a domain expert.

Depends on the nature of the business,

  • If you are a product company -> The product owner must be within your team.
  • If you are a consulting company -> Your client acts as a the product owner. In this case you need to consider Proxy PO, sometimes called as a Business Analyst within your team. S/he will act as a bridge between your team and client.

After reading this best practices, you should be able to,

  • Improve requirement gathering
  • Improve prioritization to deliver the most valuable business needs first
  • Improve client collaboration

Let’s start defining the product owner best practices to help your teams being efficient in delivering most valuable business needs faster to the end users (clients).

Create a Product Vision

The product vision is a brief statement to describe following,

  • Why the product is being developed
  • What is the purpose behind it
  • What problem does it solve for the end users

Having clear product vision lays the strong foundation for the product team. It also act as a north-star direction to move ahead. Having shared product vision across the teams Inspire and motivate every individual.

Whether you are a consulting company or product company, understanding product vision makes huge sense. For the product company it is must to have. Even if you are a consulting company, ask your client to share their product vision. Shared product vision would definitely let your teams provide innovative suggestions which usually are missing from offshore partners. Learn 8 tips for creating a compelling product vision.

Prepare Backlog

Prerequisite

The project must be created in advance, follow these steps to add a project.

Overview

Each product has its own collection of workitems known as product backlog. A product backlog is a set of the prioritized workitems starting from the most valuable on top to the least valuable to bottom. The workitem represents feature, enhancement, customer support, defect etc.

By default, you can add anyone of the following workitem types within backlog,

Epic: Act as a placeholder for set of features, enhancements, customer supports and defects.

Story: Short description of feature including its business value and targeted user. Learn how to write userstory (workitem) effectively.

Defect: An error or a bug in the application.

You can also customize workitem types in QuickScrum if necessary. For ex. If you want to add Enhancement, Post Production Defect etc. Learn how to customize workitem types.

Split Userstory

Being Product owner, your own knowledge about the product evolves. So when you start creating backlog, you generally start writing upper level story which usually are quite bigger and unclear. As you do more research and conversation with clients, you would be able to divide those big story into smaller story until it becomes executable within a single sprint.

Follow I.N.V.E.S.T rule to break down the story. Individual story should be Independent, Negotiable, Valuable, Estimable, Small and Testable. Learn how to write userstory (workitem) effectively.

Set Business Value

Business value defines how would the new story (feature) helps the end user to increase in revenue or reduce the cost. Start with asking yourself why do you need this story. Asking why would surface the business value as an answer.

Quickscrum provides 5 stars to define business value for each story.

Set Estimation Points (Size)

The estimation points are used to define the size of userstory. Quickscrum provides fibonacci series to define points. It may be complicated to understand this way of estimation but in simple terms,

  • The smaller number represents -> less efforts required to develop the story
  • The bigger number represents -> higher efforts required to develop the story
  • Infinite represents -> not able to take a judgment over the required efforts. It mainly represent work which is of kind R & D.

Main use of this method is the relative comparison. For ex. You have following two user stories,

Just by looking at these two stories, you can identify that userstory 1 is quite smaller to develop and userstory 2 is bigger and would take more time to develop. Learn how to estimate a story effectively.

Prioritize Backlog

Priority defines urgency of the development. We strongly recommend to use formulas show in the image for the prioritization.

Keep higher priority workitems on the top of the product backlog. Your backlog should be prioritized from high value to lower value workitems from top to bottom.

It would be useless to start working on any userstory without understanding its business value. Follow 80:20 rule for the prioritization. 80% of outcomes come from only 20% of the efforts. You can get more value by doing less instead of getting less out of doing more. Work smarter, not harder.

Quickscrum provides following 4 ways to prioritize workitems,

Option 1: Drag and drop a userstory

Option 2: Move a userstory to the top

Option 3: Move a userstory to the bottom

Option 4: Move a userstory to the selected position

Backlog Refinement

Backlog grooming, also referred to as backlog refinement, is a recurring event for the product development teams. The primary purpose of a backlog grooming session is to ensure the next few sprints worth of user stories in the product backlog are prepared for sprint planning. Regular backlog grooming sessions also help ensure the right stories are prioritized and that the product backlog does not become a black hole.

Backlog refinement sessions also present an opportunity for the product owners to explain the strategic purposes behind prioritized items in the backlog. These conversations can help improve alignment across the cross-functional team.

Following major activities are performed during this session,

  • Removing user stories that no longer appear relevant
  • Creating new user stories in response to newly discovered needs
  • Re-assessing the relative priority of stories based on their business value
  • Set or update story points based on newly discovered information
  • Break down large user stories into smaller one to get executed within a single iteration
  • Discuss user stories with the team, answer any related questions to smooth out any ambiguity
  • Ensure upcoming user stories meet the team’s “definition of ready” by adding key contextual information and acceptance criteria

Plan Release

Prerequisite

The project must be created in advance, follow these steps to add a project. It can be divided into multiple releases of months or quarters based on the complexity.

Overview

The release is a time boxed goal or milestone to be achieved. It contains a list of user stories to be developed known as – release backlog. It is generally useful when multiple teams are working together and interdependency exist. It keeps every team aligned. Learn how to access the release planning view.

A release should be seen as a given image below,

How to add a release?

It’s quite intuitive to add a release, though you can follow these steps to add it.

How to plan a release?

Quickscrum provides a release planning view to prepare a release backlog. Just drag and drop user stories from left to right.

Monitor Active Sprint Progress

Monitoring sprint progress without a work management tool is quite challenging. Quickscrum provides configurable burndown charts and sprint health reports to measure sprint progress daily.

Burndown Chart

A burndown chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. It is useful for predicting when all of the work will be completed. To get more insights of the burndown chart, please read here.

Monitor Average team velocity

Velocity Chart shows a comparison between The Planned Scope at the start of a timebox v/s The Amount of Work Completed at the end of the timebox over some time. It guides you with an idea of how much average Velocity is burned within every timebox. It also reveals,

Velocity is measured at the end of an iteration, so that speed of the team can be measured.

The amount of Size provided inside each timebox helps you to estimate how much work the team will be able to do in potential timeboxes. It is useful to help you determine how much work you will do during your planning meetings.

It is useful during the meetings you plan, To help you decide how much work you can make feasible.

As a result, measuring progress becomes easy, to see if there is an improvement over some time.

Here you’ll learn how to:

How to Read the chart

Filter the chart

Drill down the chart

How to use the chart

How to Read

X-Axis: Shows timeboxes name.

Y-Axis: Planned Scope: Total Planned scope by the sum of Estimated size for the number of work items.

Work Completed: Actual work completed by the sum of Estimated size for the number of work items completed.

Filters

You can view the velocity chart for the last 15 Timebox (iteration/sprint).

Drilldown

Just viewing the chart doesn’t help you enough until you can view associated work items and act upon them.

To view associated work items,

Click on any data point

Work-items get displayed just right below the chart

The velocity chart displays all work-items related to the timebox as shown in the image below.

How to Use

It is recommended to measure the Velocity of the team at the end of an iteration.

You will able to compare progress over some time.

You can list down common causes for not achieving the Planned Scope by comparing various iterations and as a result, iterations improve gradually.

Planning can be done according to the Velocity of the team so that disasters are avoided.

Monitor overall sprint completion rate

To get more insights over how your team has performed within all sprints, Quickscrum provides sprint completion rate report. This report indicates following columns,

Participate in Team Review

Scrum ceremonies allow the Product Owner to inspect and adapt. And as a result, attending such ceremonies is equal to performance. The product owner needs to join the Scrum meetings as it not only keeps the development team up to date with the priorities but also helps the product owner understand the perspective of the team if there are any impediments.

Best practices