Good knowledge of Scrum rules is necessary but by no means sufficient for being a good ProductOwner (PO). This role is extremely important for the project and for the product overall since a job well-done could turn your company into a leader in the business while otherwise sending you behind all your competitors. This implies a lot of additional requirements to the PO – a good understanding for the business area that the product targets, to start with, good working relations with customers, good communication to the team, and so on. In addition, any project and product are specific, therefore it’s difficult to provide a “recipe” for a good PO.
Nevertheless, there are a few questions that always pop up when we do training or later on when the teams start applying Scrum. In this article, I will try to point you to some directions where you can look for answers to these questions when you are confronted with them.
Q: How detailed backlog items should the PO write?
A: Among the biggest challenges a PO faces is learning to tell the team “what” they need to do, and not “how” they should do it, especially when the PO is familiar with the technical details of the product. Therefore, writing very detailed descriptions for the backlog items might turn into creating a design document or detailed specification that doesn’t leave too much freedom to the team to decide how they want to handle the problem they have to solve. Even if you are pretty convinced that with your huge experience you can provide the best solution, in the backlog item describe only the problem and let the team look for the answer; thereby, you might get a more innovative and efficient solution than anything that was done before. At the same time, however, you should avoid too abstract or undefined backlog items. I’ve seen this happen when user stories are applied. Indeed, user stories imply a short description and a lot of additional communication between PO and team, but there is a very important and often neglected aspect in them – the so-called acceptance criteria/test. When you define the acceptance tests, you actually explain what results you expect to get and provide the team with information on the different aspects of the problem to be solved.
As far as the team is concerned, the factors that also define the need for a more detailed description are team maturity (the time its members have worked together as a team) and the level of cooperation with the PO. When you work with younger or unfamiliar teams you’d better include more details in the backlog item descriptions until you find the optimal way for communication and requirement clarification.
Q: How does the PO prioritize backlog items?
A: Prioritizing starts with the initial definition of the product backlog. There are a number of techniques you can use for that. Here is one of the options. After listing the stories and before doing the initial estimate with the team, it is a good idea to split up the requirements into the following groups:
- Nice-to-haves (or as Mike Kohn calls them – exciter features)
- Items that are interesting in general but not important (for the current product version) and can wait.
It is then clear that the team will first focus on the first 2 groups in the list. By doing this, you already have defined the high-level priorities. The next step is team’s initial estimate. When you already know what implementing each of the items would cost, you could remove some of the items in the should- and nice-to-have groups, if they are too expensive and do not bring much value added to the product. If needed, you can go further and add more detailed priorities within the groups (this is typically necessary for the should- and nice-to-haves, but sometimes also for the must-haves – for example, if you are planning an alpha- or beta version and would like to have particular features included). You can find an interesting tool that you can use for the prioritization exercise here: http://www.mountaingoatsoftware.com/tools/relative-weighting.
Q: What can the PO do in the case that several items need to be delivered urgently?
A: You have different options to react based on the scope and the size of the project. If you are working with several teams, you could focus all their capacity on those items by including all of them in the respective sprint backlogs. If this is not an option for you, you could try to re-define those requirements, so that they include a limited scope, hence less time to implement (for example, if the whole story refers to the possibility to store and edit personal data, as a first step you could limit the requirement to the possibility of storing that data, and as a second step – editing it). This will allow you to demo a working product increment and get feedback from stakeholders at the end of the iteration, even though the entire vision is not in place yet.
If none of the above is possible, your alternative is to talk to the customers and discuss priorities again. Tell them what your plans are and why capacity is not enough; show them why the features you plan to deliver will be useful to them.
Q: How can a PO require high quality from the team?
A: In Scrum the team shall guarantee the high quality of the product. This is something the team discusses with the PO at the beginning of the project, and typically goes into the team’s definition of done. In spite of that, PO could help the team achieve better quality by defining good functional tests (I mentioned the so-called acceptance tests above). In addition, (s)he must be available for questions, demos and feedback during the entire sprint, so that rework is not necessary later.
Q: What can PO do if something is not completed on time?
A: Sometimes what you still need to do does not bring too much additional value to the product – for example, moving an element to the left or to the right on a web page or changing a button label in the application. You can decide that such backlog item is complete. However, when critical items are incomplete, especially when they are part of the acceptance criteria, you need to put the item back to the backlog, prioritize it and the team needs to re-plan it the next (or later) sprint. Every delay needs to be communicated with the customers or other stakeholders, as it might have an impact on their schedule as well.
Q: How can PO help the team?
A: PO must help the team understand the requirements in detail, so that they can offer a good solution. To achieve this goal, PO needs to have enough time dedicated to the team, so that team members can find PO for discussions or preliminary demos. Furthermore, as a PO you can spend some time testing the already completed items and giving fast feedback to the team, so that they can apply it within the iteration.