It's ALSO a Full TIme Job: Product Owner By the Numbers


It’s ALSO a Full-Time Job: Product Owner by the Numbers

Far too often an organization misjudges the amount of time someone spends while functioning as a Scrum Master, either too much OR too little. In response to many student requests, I developed a blog post a while back, breaking down how a Scrum Master would spend their time during a two-week Sprint:

https://www.sparkplugagility.com/blog/scrum-master-it-s-a-full-time-job

Of course, the follow-up question that inevitably comes up is...
 

“Okay I get that, but is being a Product Owner really a full-time job too?”

This blog post breaks down the role of Product Owner into typical activities for a two-week Sprint and hopes to provide a starting point for impactful discussions in your organization. Being a Product Owner is a challenging and difficult job. Often, and for many different reasons, this person is not able to effectively function in the spirit of the role. Three of the more common challenges are:

  1. Lack of a shared understanding of Scrum within the organization.  With a lot of "bad scrum" out there, not having a strong foundation in the fundamentals can cause a lot of pain and frustration.    
  2. The person selected for the role of the Product Owner is not set up for success by the organization.  This normally includes receiving no training courses, no books or resources, or coaching & developmental support from experts in the field.    
  3. The new Product Owner's approach may be rooted in a traditional project mindset, where one person alone would identify what needs to be done, how the work would be done, when it would be completed, etc.

A huge part of what makes Scrum a great way to work is the focused discussions that teams have, namely the Sprint Events; Backlog Refinement, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective. Product Owners have a different part to play in these activities, sometimes being extremely active in discussions and sometimes in more of a support role.

Backlog Refinement is a continuous activity where Scrum Teams add the appropriate level of detail, estimates, and ordering to items in the Product Backlog. Teams should spend approximately 10% of their capacity on this activity.

For a two-week sprint, a team could spend one hour on eight of the ten business days of the Sprint working on refining the Product Backlog. Imagine having conversations centered on 3 to 4 backlog items each day, not unreasonable at all.

Sprint Planning is the first activity that happens in a Sprint, forming the Sprint Goal and Sprint Backlog. Teams are time-boxed to 8 hours for a 4-week sprint or about 2 hours for each week of the Sprint. So for this example a team would spend four hours creating their Sprint Goal and Sprint Backlog for a two-week Sprint.

The Daily Scrum occurs every 24 hours. Team members have a conversation with one another (aka, not a status meeting) to align activities that enable them to meet the Sprint Goal. This is time-boxed to 15 minutes each day.

What teams often miss though is that the Product Owner is an optional attendee, and may be invited by the Development Team. As a result, we won't count any Product Owner time for this activity.

The Sprint Review is the event where the Scrum Team demonstrates the increment to attendees and elicits feedback. Questions are asked and answered, and collectively the group figures out what to do next. This event is time-boxed to 4 hours for a four-week Sprint, or about one hour for each week of the Sprint.

For this example, let’s say our Sprint Review takes 2 hours for our two-week Sprint.

The Sprint Retrospective is the last activity in the Sprint where the Scrum Team reflects on the Sprint and identifies ways to make the next one a little bit better. The Sprint Retrospective is time-boxed to 3 hours for a four-week sprint, or 45 minutes for each week of the Sprint. For this example we will include 1.5 hours for our two-week Sprint.

In addition to time spent in these events, very often Product Owners connect with participants before and after the session. Think of the "pre-meet" where you may huddle up in preparation, or the "hey stay after a bit for some post-game talk" conversations. This time (aka, 'event overhead') is going to occur for most meetings. Fifteen minutes before and after each meeting (beyond the time spent in the meeting itself) is a reasonable estimate of time to expect for these side-bar discussions.

In summary, here is a quick snapshot of how Sprint Events could align using two-week sprints. Note: The Sprint starts on a Wednesday and ends on a Tuesday:

Considering the timing of the examples above, here’s how the breakdown of Sprint Events would look like in a table:

So that doesn't sound like a lot, right? There's a WHOLE BUNCH of time to get all of that "real work" done that you are being pressured to work on, correct? Let's keep looking at how the days could unfold; it may surprise you!

Every day, a Product Owner has many activities on their plate. Being a Product Owner is about making decisions, often with imperfect and incomplete information. They help others get to a place of mutual understanding by providing answers to questions and getting clarity on Product Backlog Items (or PBI for short). For each PBI, a Product Owner may need to have additional conversations and analysis to determine: 

  • "Who" - the person whose life is impacted in a positive way if this PBI becomes a reality 
  •  "What" - the action that the person wishes to take    
  • "Why" - the reason that person needs to take the desired action    
  • "Verify" - how the Scrum Team can verify that this person can indeed take that action, i.e. Acceptance Criteria

Each of those parts of a PBI could take 15 minutes -each- to identify, so expanding that one PBI could take 60 minutes to refine one PBI each day.  And that's just for the first pass!  


Another Product Owner activity to consider is ordering of the PBI contained in the Product Backlog (some people like to say "priority", I prefer "ordering").  A Product Owner must usually conduct several activities to help make decisions about PBI order.  These could include:

  • Stakeholder conversations - those who have invested in the product 
  • End User conversations - those who use the product   
  • Decision Making activities - leveraging models such as "Kano" to aid in analysis    
  • Market Research – determining ripe areas for the product, or presence of the competition 

If we set aside 15 minutes -each- for these areas, that takes up 60 minutes or one hour, each day. You may think this is not enough time, and I would agree with you! Let’s keep building this part of the picture though.


Even if a Product Owner has all the information that they need to refine PBI, they still have other responsibilities to perform on a regular basis as a Product Owner. These could include:

  • Writing and Refining new PBI - creating the initial draft of a PBI, along with follow-ups for refinement.  That first pass could take 15 minutes; a second opinion may take an additional 15 minutes. 
  •  Getting PBI to "Done" - working with the Development Team to review the Scrum Team's Definition of "Done" (accepting work, for those scoring at home).  Scrum Teams that I have been on would have these conversations anywhere from 1 to 10 times EACH DAY.  Getting one PBI across to "Done" may take 15 minutes of the PO's time.    
  • Collaborating with others - Meeting with members of the Scrum Team, other Product Owners, Stakeholders, or people in the organization.  It is not unreasonable to expect 45 minutes of collaboration each day.    
  • Improvement Activities - after the Sprint Retrospective, a Product Owner may have actions to help improve the Scrum Team in the next Sprint.  These actions may take 15 minutes each day (I know, seems short...) 

If you roll all of these into one table, Our two-week Sprint example could look like this:

It's starting to add up a bit isn't it? PLENTY of time left over... right? Let's keep building the picture.


Product Owners should always be looking to improve their craft. This could be learning a new skill, reading a blog post, anything that makes them stronger in their job. Let's set aside 15 minutes each day for that (yeah, I think it's not much either).

They also may interact with other Product Owners, sharing success stories, speaking about the Product to other people in the organization, or participating in User Groups, for example. These activities help the organization grow in their Agile Mindset, and we'll set aside 15 minutes each day for these activities, too.


But there are also a few "hidden" activities that take more time than you realize.

For instance, you need to eat!

Yes, I know, you can't bill for that time (joke for those of you in contracting) but it still takes time. It's perfectly reasonable to assume that you'll need to fuel your bodies so you can continue to function. Let's set aside 45 minutes for this. Yes, you take a short lunch, I get it. Stick with me.

You also need to move around. This could mean walking to a co-worker's area, heading to a meeting room, another part of the facility, or another building on your campus. Let's set aside 15 minutes while at work to moving around.

Now there's one huge time-sink that we all have to deal with every day. Context switching, the hidden killer of productivity. Just switching between those three email threads takes time and energy. Trying to keep your "to do" list in your brain can wear you down. Changing your train of thought between multiple initiatives takes its toll. I'll set aside 45 minutes a day for context switching when in reality it's probably much more.

Here's how all these things look in another table:

For those of you scoring at home, these numbers really start to add up. Frankly, it’s a bit overwhelming, but also illuminating. Let's put it all in one big picture:

510 minutes, or 8.5 hours a day 5100 minutes per sprint, or 85 hours.
 
Let that sink in. That’s a lot of time!

Quite a lot, isn't it?

Now some of you may be saying things like "No way do I spend that much time," to "You also forgot about all this other stuff that I do," among other safe, or not safe, for work phrases  :)  Remember that this is an -example- to use as a basis for discussion.  There are busy times, and slower times, but if you average things out it probably looks close to this.     Now keep in mind what this does NOT include:

  • Tool administration for all those reports and documents 
  • Managerial actions such as writing performance reviews, updating job postings, and interviewing candidates    
  • Release management activities to get those great products out to market    
  • All that "Real Work" that someone may ask you to do since this can't be a real job.....right? 

Want to know the scary part? The example above is for -one- team. That's right, ONE Scrum Team! This is the basic, low-bar, expectation of what an organization should ask a Product Owner to do on a regular basis.


Do you find yourself in the position where the organization is asking you to act as a Product Owner for multiple teams?

Being a Product Owner can be challenging when working with ONE TEAM, and there are even more potential challenges when dealing with MULTIPLE teams: 

  • Answering questions and providing clarity takes time for one team – double it! Triple it! 
  • Maintaining the Product Backlog is one of your top responsibilities – double that work! Triple it!    
  • Context switching between different products / teams makes it difficult to “keep up”    
  • Interfacing with at least two completely different user bases or sets of stakeholders    
  • Working with at least two development teams, and sets of personalities    
  • Working with, and building chemistry with, at least two different Scrum Masters! 

Being a Product Owner for ONE TEAM in itself is a full-time job – so how do you feel about multiplying it?  

*deep breath*


So, now that I've got you thinking, it's up to YOU to use this article in a productive way. This could include: 

  1. Scheduling a talk with your Scrum Team to see how tough of a job this is 
  2. Sitting down with your Scrum Master to talk through how busy each day can be    
  3. Meeting with those in the organization that may be asking you to do too much

So if you are asked "Is being a Product Owner a full time job?" you now have something to sit down, point at, circle, and discuss.  Being a Product Owner is a rewarding, fulfilling, and challenging job.  Leaning on knowledge, training, techniques, and intuition will help you in the long run.      

My hope is that this helps you start the conversation about the role of Product Owner in your organization, and to get them the support they deserve.  Thanks for reading!   -CL




0px

© 2024 Sparkplug Agility