Category Archives: Scrum

Your first Sprint as a Product Owner

Scrum is getting more and more popular. And one role that doesn’t get too much attention is actually one of the hardest in my eyes. The Product Owner.

This blog is dedicated to help professionals grow their skills as Product Owners or start to become one. It is driven from experience of working more than 5 years as a Scrum Master together with Product Owners and being one myself fore more than 1 year. If you came here as reader of my old blog better change your bookmark since this will be the new address where I’ll provide you with content from now on. Together with my 2 partners in Oikosofy Vasco Duarte and Luis Goncalves we’re providing you with everything that you’ll need in your venture to become Agile, Lean and create products that matter and delight your customers.

Who is this for?

You’re brand new in the role of Product Owner or you’re planning to become one in the near future? Then this is for you. It also helps people new to Scrum to understand better what the role of the Product Owner includes and how what a Product Owner does in reality.

  • Product Owners
  • Scrum Masters
  • Leaders looking to use Scrum for their organisation
  • Anyone interested in getting insights to the role of Product Owners

ProductOwnerTeamStakeholders

Assumptions

For this rough recipe the following assumptions are used:

Sprint length: 2 weeks
Testing: mainly done manually
Team: collocated in one room
Stakeholders: All in the same location and country
Backlog: The product backlog is already in place and filled
Planning: A roadmap reflecting the current and upcoming sprints exists

In the next part I’ll describe some of the major Scrum activities as well as the specific Product Owner duties and activities. This is an exemplary list and kind of “by the book”. You’ll rarely find a Product Owner doing all these activities. But if you start doing it you should aim high, no?


Your very first Sprint as Product Owner

Day 1 – Sprint Planning

The Sprint always starts with the Sprint Planning. The Product Owner brings along the Stories that she has prepared beforehand and ordered in terms of criticality and business value to present it to the team and then together collaboratively create the Sprint Backlog. Depending on the preparation this can last from as short as 20-30 minutes to 2-3 hours (for a 2 week sprint).
The goal is to have a common understanding of the Sprint Goal, the scope of the sprint backlog defined, the Stories well understood by the team and Acceptance Criteria defined to be used at the end of the Sprint for the Sprint Review.

  • Set the sprint goal
  • Motivate and engage the team for a challenging yet doable Sprint

Day 2

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 3

  • working with Stakeholders to update Release planning and Roadmap
  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 4

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • working on the Product Backlog to prepare the PBR

Day 5

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • finishing the preparation for the PBR to fulfil the Definition of Ready

Day 6 – Product Backlog Refinement

In the Product Backlog Refinement the Product Owner and the team can clarify upcoming topics. These could be epics or features that haven’t been further analysed and need clarification. The Product Backlog Refinement is a good occasion to break Features down to Stories and add useful information to the Stories.

  • answering questions of the team
  • (optional: reviewing and accepting Stories)

Day 7

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning

Day 8

  • answering questions of the team
  • (optional: reviewing and accepting Stories)
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 9

  • answering questions of the team
  • clarifying open questions from the PBR in preparation of the Planning
  • working on the Product Backlog in preparation for the Planning
  • negotiating priorities for the Product Backlog with stakeholders
  • updating Release Plan and Roadmap with stakeholders

Day 10 – Sprint Review

In the Sprint Review the Committed Sprint Backlog will be reviewed in the form of running tested software. The Product Owner and team will check if the agreed Definition of Done is fulfilled for each Story and will reject Stories that don’t fulfil it.
The Sprint Review is an open event that everyone can join and especially real end customers can and should take part in it if possible.
The Product Owner as spokesman for the customers will decide what’s finished and can be released to the public and what not.

  • Celebrate with the team
  • Thank the team and give them a small pause to do the Retrospective and recharge batteries

What next?

This is an exemplary schedule of a Product Owner.
A Product Owner should always aim to have exactly the availability that the team needs to answer questions or review work in progress. Every hour that can be saved for reworking Stories that weren’t finished as “intended” during the Sprint is a big saving compared to do it after the sprint.

Managing the Stakeholders is a difficult task. Especially balancing the time used for meetings with stakeholders versus working with the development team. If you can get this right, you’re set up for success. Many Product Owners that I’ve worked with were swamped with meetings trying to please all stakeholders and left the teams alone during the Sprint. This is an anti-pattern that should be avoided.

If you liked this post sign up for more.
This blog will be a source mainly for Product Owners and related topics.
In future posts I’ll dig deeper in what you saw under Assumptions. E.g. creating your first Product Backlog and how to do regular Roadmap updates and Release planning.
In case you don’t want to miss out on that, sign up.

Sven Schnee