The Product Owner Manual is a short e-book available for free from ScrumSense. It discusses in a practice-oriented way the roles and techniques used by a product owner in Scrum teams, including the story writing principles and how to perform release planning.
The product owner role is crucial for a Scrum team because as the book states it ” A good ScrumMaster can take the team to the point of being self-organized and motivated; they can help the team achieve good Scrum. But to achieve truly great Scrum, an empowered, dedicated Product Owner with a strong vision is crucial.” This manual provides a concise but rich material on many of the aspects of the product owner activity from user stories and backlog grooming to release plan production. It offers also an interesting reading list that will allow the reader to dig further on the topic.
This short book provides a valuable introduction to the roles and techniques used by a product owner in Scrum teams. I will recommend it naturally to every people who envisions to fulfill the product owner role, but also to every stakeholder of a Scrum project so that they could better understand what they should expect from their product owner.
Reference: Product Owner Manual, Peter Hundermark, 26 pages, http://www.scrumsense.com/resources/product-owner-manual/
Quotes
If we contrast the traditional project manager role with that of the Product Owner what stands out is the emphasis on empowering a single individual with the authority to decide both scope and schedule. The project manager is usually forced to emphasise the cost of change and limit it to de-risk the project. This is in stark contrast to the Product Owner who must be empowered to decide and influence scope through an understanding of the domain, value and priority of requirements.
The Team should as far as possible communicate directly with the user community. Sometimes this may be the same as the customer (if you are dealing with a direct customer facing product). However, where this is not the case (as in many enterprise scale applications) having the Product Owner as a proxy or conduit for information from users is not advised. Face-to-face interaction (or at least direct communication) between the user community and the Team reduces the likelihood for miscommunication. It is often the case that the ScrumMaster might interpret their mandate to “protect the team” over-zealously, and attempt to limit or eliminate interaction between the Team and users. However, this information is essential to the team. The ScrumMaster should be protecting the team from interruptions, not information.
The ability for the team to know, rather than assume, removes the possibility of creating waste. And to ensure that this happens the team must feel that the Product Owner is there to support them by providing the needed guidance. If the Product Owner cannot answer their question, his immediate priority should be getting the answer. A good metric to aim for as Product Owner is that 85% of the team’s queries should be answered in 15 minutes or less. You’ll quickly realise that to accomplish this, requires co-location with the team.
As a product owner, your chief responsibility is determining the priority in which work should be done. My recommendation is that you treat bugs just like any other type of work. Identify the business value of fixing and impact of not fixing the bug and schedule it relative to other stories. I would recommend that you dispense with the usual story format for bugs; the fit is usually poor. What I think it vital however is that the test cases for the bug are clear.
And finally, a technical debt story should be written, estimated and placed in the backlog to be prioritised. This allows the Product Owner to track the accumulation of technical debt and make informed decisions as to the longevity of the product’s code base. It also creates a transparency allowing all stakeholders to remain informed of the code’s level of technical debt.