What Does One Sprint From a PO’s Life Look Like

What is a typical routine for the Product Owner throughout one full sprint?

The exact definition of the Product Owner (PO) role and the responsibilities are described in the “industry bible” — Scrum guide — which mostly describes us as product backlog “carriers,” who prioritize the backlog items☺. It is true, the PO is the person who should always keep their finger on the pulse of the product roadmap. But let us now go deeper and see what the PO’s role looks like in a decomposed state and what the Scrum Guide does not say about us.

I will try to share the experience and knowledge I gained over time and hope it will be helpful for those who plan on starting a career in this area.

One major note that I would like to make before jumping to my “lovely” structured list is that PO’s responsibilities can vary based on the team structure at a given time. Not all roles are always available in scrum teams and to some extent, the PO can share some of them. For example, a Scrum Master (SM) may join only at the beginning of the project or may not join at all. The PO is the person who might take the responsibilities of such kind (same implies to the responsibilities of project and product managers, business analysts and quality assurance specialists). That’s why I will be providing the things that I came across throughout my own experience in the role of a PO for a B2B product.

I have grouped my activities into 3 major chunks: things inherited from the previous sprint to make to the finish line, activities related to the current sprint and, most importantly, working items to prepare and finalize for the upcoming sprint(s).

Previous sprint

The “great gift” that follows every sprint completion is production deployment. Having the previous sprint closed and the development complete is not yet an indicator to change the focus. The ready-to-go items should reach the production and the end-users. Here are the steps I follow to arrange the deployment:

1. First, I make sure that the increments from the completed sprint are actually “ready-to-go.” They need to be properly tested and verified (usually on the acceptance environment) and should meet the acceptance criteria. In the case of problems, they should be either addressed before the deployment or should be moved to the future sprints based on their priority.
2. Second, I talk to all key stakeholders who are responsible for the verification. I get their confirmation and agree on some logistics. This involves deployment time and duration as well as the deployment plan.
   And keep in mind — never do deployments on Fridays and in the evenings. Sometimes side effects occur and you might need extra time to address them.
3. Then I proceed with the deployment organization. I talk to the development and DevOps teams on the items that were decided in the previous step and follow up on the execution.
4. And finally, I update the documentation regularly. It’s key for a PO to keep and track the documentation. Once every chunk of increments deployed to production are properly versioned, I prepare some internal documents (usually in Confluence):

• The list of stories/tasks/bugs deployed under each version. Here is how you can do it.
  As I like to keep all related information in one place, I also put the changelogs of each microservice from the CI/CD tools (in our case it is Jenkins) for each environment, the microservice versions (they may vary as changes may affect only several) and the deployment dates.
• The roadmap. I update the list of features we have delivered in a certain time frame and make some auxiliary adjustments for the future.
• Technical documents: The development team keeps special documents for deployment activities. I check it every time in case I need to provide any complementary information.

Evidently, the more mature the project is the more stable the processes are, including the deployment processes. I will try to cover this topic more thoroughly in a separate article.

Current sprint

In this group, I present activities that are necessarily conducted during every sprint and are about the current sprint.

1. Scrum events

This classic group includes the major events/meetings that regularly happen each sprint and require preparation, thus they also “eat” a good amount of your time.

Sprint planning: The big day of the sprint. You need to be well prepared for it, which means having a clear sprint goal, user stories groomed and verified (and yes, chocolate and sweets too).

However, don’t expect this all to be smooth and easy.. Quite often, there are last-minute changes or requests that are very important and both you and the team try to be more “agile” here. What I recommend you to do is to try filtering such last-minute requests. See whether such issues block the product and business-main flows or no.
In general, here is a quick sprint planning checklist:

• Present the goal for the next sprint. What features are to be delivered and highlight the most important ones for the team to keep the focus on.
• Go over the board of the past sprint with your team. You may move some subtasks, close the finished stories if not yet done so, etc. and eventually close the active board (we use Jira as a project management tool). The open stories will automatically be moved to the current sprint backlog.
• Clarify the questions raised with the team and elaborate on acceptance criteria.
• Confirm the team capacity, always keep some reservations for production incidents and deployment activities. If the team has an SM s/he is in charge of this.

Standups: Again, If an SM is not available, the PO conducts the standups. Tracking the work done, work in progress and work remaining, knowing what everyone is working on are the main takeaways from standups from the perspective of the PO.

Sprint reviews: I jumped to the end of the sprint right away, but this is the next scrum event in series (I intentionally skipped grooming sessions here as they refer to upcoming sprints in general). Well, what I constantly do to prepare and run an effective sprint review/demo session:

• Test and verify ready user stories. If the team has a quality assurance specialist, then the PO needs only to verify the acceptance criteria. If not, the PO does all manual testing. I do test and verification throughout the sprint — once a story is ready for testing from top to bottom in the sprint backlog. Developers will have time to cover the feedback if any.
• Prepare a sprint review presentation based on the completed and delivered stuff. This helps to run demos more constructively. I keep one demo presentation template for this purpose.
• Prepare some sprint reports/updates for stakeholders. Not all stakeholders participate in demos, thus I send them updates separately — the list of changes delivered and some general stats for each sprint (i.e. velocity, time estimated vs spent, etc.).

Retrospectives: Retros are meant for listening to the team’s feedback.time. Quite often, there are issues that can be addressed by just becoming aware of the feedback. Here is a good source with a bank of interesting retro ideas. The SM is usually responsible for retros. If s/he is not available, the PO takes it over.

2. Production issues / incidents

All the things till now are mostly well-planned, the big wrecking balls are incidents, which are quite a common occurrence in every application.
I would say that people usually want the PO’s attention to those incidents, even though the development team leads are more than capable to handle those independently. You may spend a lot of time explaining the issue, its impact and the possibility of recurrence.

3. Communication

Yes, lots of communication. Series of meetings, both scheduled and unscheduled, happen each sprint in addition to the regular scrum meetings: status update meetings, daily product team discussions, calls with different stakeholders. To handle them effectively, I would recommend being organized.

Confluence has different templates for running every type of discussion, try to put them in use. For example, before the meeting, prepare all discussion topics in a meeting note template and put any supporting information — Jira links, and descriptive documents that can be used. After, summarize the decisions made and action items. Check out here to see the existing templates in Confluence Cloud and the detailed description. By the way, you can create your own as well.

4. Documentation

Though the Agile framework does not imply many documents they do not eliminate them as well. Summing up the business requirements for every feature in the application in one place (usually confluence) and regularly updating them serves as a one-stop-shop place and a good source of truth for future references.

Besides the business requirements, you better keep some “organizational” documents that will support the story writing process and the development in general. For example, keeping one page in confluence for field validations will save lots of time for story writing (for let’s say every new form and will refer everyone to a single source of information).

Also, the more you manage to document the smoother and easier the processes will go. For the product team discussions and in key decision-making processes it is always better to describe the current issues and challenges prior and first in writing, provide the list of possible solutions along with the advantages and drawbacks of each.

Next sprint(s)

Here comes the key chunk of work that a PO is basically responsible for, and I would say this is the most interesting part that is conceptually unique every time. You keep the process the same, but the features are new every time.

Knowing what to work on in which order are the main things that you should always keep your focus on. And those things are elicited from the Product roadmap, which is a broad overview of all parts of an upcoming product: goals, milestones, timeline, features, priorities, etc. This information is mainly generated from three groups: business stakeholders, product user community, and your own product knowledge. A big meeting — Release planning — finalizes the expected features to be implemented in a certain time frame.

1. Features: Once you know what features you should work on, start getting deeper into the topic and the requirements. Talk to the development team leads, consider the side effects, possible use cases. Have some rough estimations for each feature.
   For those that have been confirmed for implementation, start preparing the mockups. You work on and refine several big features for the next 1–2 sprints to be implemented. This depends on the team size as well.
2. Visualization: Once the business requirements are clear, move on to elaborating on the visual aspects. Prepare mockups for representing the structure of information, the content, the basic functionalities in a static way. I use draw.io, Axure RP for mockups.
   After I discuss the mockups with the product team and we have a final decision, I approach the designer to bring everything together in a final design. Quite often teams have their “dedicated” designer and they prepare the mockups as well.
   Having prototypes in place will help to test the main interactions in a way similar to the final state. InVision works pretty well for prototyping.
3. Prepare user stories: As soon as you have a clear understanding of the features you are working on and the ready visuals, you can prepare the user stories right away, the sooner, the better. Most likely, you need a new epic in Jira, which you should divide into multiple user stories. There are different techniques for user story writing, I practice the Gherkin — it is a behavior-driven language syntax developed by Cucumber. Check out for details.
   For effective story writing also use Jira text formatting tools. See the full list. And one important note — always keep the stories updated.
4. Groom the stories: Try holding multiple grooming sessions within one sprint (i.e., 4 for a 2-week sprint). You adjust the stories, understand the complexity (sometimes break them down to multiple stories). The meetings smooth out any ambiguity and ensure the team’s awareness of further stages of the product.
5. Refine the backlog: Go over your backlog at least once each sprint. Do not only adjust the priorities but also take some tips to avoid the bubbling backlog. Here is what I usually do:

• Improvements: During the development process you may “generate” multiple improvements related to the same feature. I try keeping one big story with all improvements needed for each feature and pick up the most important ones over time, instead of creating separate tasks for each and avoid a backlog with hundreds of stories.
• Bug fixes: Sometimes different people report the same bug (yes, the PO is usually in charge for this, but it is a common practice), or in another scenario, the team might add low-priority bugs to the backlog. However, those can get a higher priority over time.. What I do in such a situation — I try keeping bugs grouped and take the important ones for the upcoming sprints. This way you can make sure no critical bug is accidentally skipped.
• Technical tasks: Add all small technical tasks under one parent task (and ask the developers to do so as well). During every sprint planning, discuss the necessity of doing the most important ones and include them in the sprint. There might also be technical stories. You better create them separately as they will be divided into multiple subtasks.
• Feature ideas: I would recommend not adding a draft story every time you have a new feature idea. I keep one page in confluence and put every such idea there. We can go over it from time to time during product discussions.

Other areas that Product owners may be involved

In addition to the regular activities that a PO performs during each sprint, there can be some additional ones too.

Research: This is a very important activity and can be carried out in different stages of product development, especially during initialization. It is essential to get insights about the market, competitors, and most importantly, customer needs.

Project initiation: Project initiation involves all the work prior to the full development start. The process includes several steps from preparing the project brief, release plan, high-level requirements to setting up the infrastructure and forming the team. I will try to cover this topic as well in the future.

Product metrics and analytics: Setting up product metrics and using analytics tools provide useful data on user behavior, be it quantitative or qualitative, and serve as a ground when making product decisions and building new features. If there is no existing data to be found, you might consider using A/B testing to see if your change had the desired effect.

Another great option is getting feedback from real users. You can ask your friends and colleagues to give feedback on their experience with the product. Or you can use external services for user testing.

As you may have noticed, these areas have a big overlap with Product manager responsibilities, and depending on the project type, the Product Owner may partially share them.

Summary

A PO’s role is quite dynamic and challenging because it requires a wide skillset. Context switching is also an important skill to master here, as in a daily manner you may jump between meetings on different topics and do various activities and interact with many different types of people across the company. That is a great part I love about my job. I never get bored.

Want to join our team?

Check out our open roles at https://sflpro.com/job/.

Let’s talk!

Read More:

IT Managers: Who Owns What?

Minimum Viable Product: 4 Steps to Making it Right