What the PO Does During the Sprint?

Somebody asked me an interesting question: what does a Product Owner do during the Sprint? But before answering this question, let’s go one step back and see what the PO does for the release backlog.

Let’s start by saying that the PO has changing roles and responsibilities during the project. For instance, during the very inception of the project, the PO would be responsible for gathering the initial set of requirements–provided by the client–and together with the team, create an initial set of user stories.

This initial set of user stories is prioritized and estimated–using Planning Poker, T-shirt sizes or any other technique–by the team and the PO. This prioritized list of user stories is what accounts for the initial backlog or release backlog. One caveat, estimations provided in this stage are related to complexity, not to time or effort.

Building the Sprint Backlog

The sprint backlog should be a subset of the product backlog that the PO and the team agree to be worked during a time-boxed period of time: Sprint.

During the planning stage of the Sprint, the PO in collaboration with the Scrum Master are responsible for guiding the team in providing time estimates for the committed user stories. Over-commitment is hard to avoid in the first sprints because the team isn’t aware of its own velocity.

Based on the time estimates provided for each user story, the PO can calculate–adding up all the user stories times–the total number of hours that the team would be working on the Sprint. This number of hours is the total capacity allocated or hours to be burned during the Sprint. Making sure that these hours are burnt–and the associated user stories delivered–would be one of the key responsibilities of the team during the Sprint.

Running the Sprint

Scrum recommendations limit to say that the PO has to be available for the team during the planning stage and also during the Sprint, in case the team has additional questions. The PO also has to prioritize and reprioritize the backlog on a need basis. But it would seem that doing all this wouldn’t take much time, at least not to keep him fully busy during a three-week Sprint. This is one of the Scrum myths that I'll try to demystify.

So, let me bring some light to what the PO should be doing to stay entertained during the Sprint:

1. The PO should be in contact with the client showing and discussing results from the past demo. Showing something to a client just one time is usually not enough to have an accurate perception of what he liked or not from the product.
2. Clients are not always available for the PO, so chasing clients will consume cycles from the PO.
3. If the PO is working with a product targeted for multiple clients, the chasing/demoing activity increases exponentially consuming even more time.
4. Demoing a product without the team's assistance implies that the PO has to set his own environments and learn the product well enough and not only from a user's perspective. This is not a people's activity; it is more technical and will consume many cycles from the PO.
5. By using the product in his own environment, the PO will be discovering what I'd call "requirement issues". In fact, the PO will be doing "requirements testing" which is a validation of the product from a client’s perspective. Passing this test would guaranty that the PO has something he can sell.
6. Studying the market and monitoring competitors should also be in the PO’s agenda.
7. Defining new requirements based on client's feedbacks and market reading.
8. Adding new user stories into the project backlog by his own initiative and/or per team’s requests is pretty obvious, what is not so obvious is that the PO needs to ask the team to do some planning poker to estimate complexity for the recently added user stories and that the backlog would need to be reprioritized.
9. Grooming the backlog to accommodate new and changing requirements should be the tangible output from the PO's work during the Sprint.
10. Building and monitoring a burndown chart is also crucial for POs. Actually, the burndown chart should be used by the PO to see if the allocated hours are being burned at an acceptable rate that can be used to predict that all scheduled work would be completed on time.
11. Frequently enough, the burndown chart will show that the team is more likely to miss the mark, in these situations, the PO has the responsibility to negotiate whatever can still be completed on time. Having a bunch of user stories in progress is not as good as having a few completed–walking skeleton principle–.

As you can see, the PO has enough–and maybe more than enough–to keep him busy during the Sprint. One note thought, Scrum doesn't prescribe that the PO's tasks should be planned and tracked on a separate backlog, but what if some PO decides to do so? I'd be happy to hear about the results of this experiment.