The Scrum Guide, the official definition of Scrum, created and described the role of Product Owner (PO). The role is described as “responsible for maximizing the value of the product and the work of the Development Team” . It’s a challenging role; as it requires someone with technical ability, business analysis ability and authority to make decisions and deal with the consequences. It is often considered to be the most difficult role in Scrum [2, 3, 4].
There are a number of tools available that can help the Product Owner be successful. This post describes one such tool, called the PICK chart, which can be used to aid planning and prioritisation between the development team and the stakeholders in the business.
PICK your Stories (and Battles)
The Scrum Guide describes the Product Owner’s responsibility as “the sole person responsible for managing the Product Backlog” . Commonly this is interpreted to mean that the product backlog is a one-dimensional list of tickets ranked by business value. This is a bad idea. By ordering in this simplistic manner, some low-value stories remain untouched by the team for a very long time (sometimes years). The stakeholders who requested this work are effectively placed at the end of a queue only to see others skipping in front of them.
At the top of the product backlog, a one-dimensional list also causes problems for the unwitting Product Owner. This is because some valuable tasks are straightforward to implement and others are complicated or have very high levels of uncertainty.
The INVEST  and MoSCoW  techniques can help improve story refinement and prioritisation. INVEST ensures that each story satisfies certain criteria. It doesn’t provide a ranking criteria as long as these criteria are met. MoSCoW provides a method for managing project scope and identifying out-of-scope and at-risk items. It tends to be subjective and why an item is in one of its four categories rather than another can be contentious.
A PICK chart, similar to the one shown below, is a useful method of addressing the weaknesses of existing methods while also meeting the needs of the team and stakeholders:
This two-dimensional chart shows both the potential value and the likely difficulty of each story. The y-axis shows the value (“payoff”) from delivering story and ranks the highest value to the top. This is similar to the usual lists used to display product backlogs. The x-axis shows the effort required to deliver a story. Stories on the left have lower risk as the effort required to deliver is less than those further to the right.
The PICK chart can be used effectively during sprint planning to help the Development Team select stories that can be implemented in the next sprint as well as identify work that needs further investigation. This helps ensure the sprint does not consist entirely of high-effort, high-risk stories.
The chart can also be used as a visual tool to remove stories from the bottom of the backlog because they are both low-value and technically challenging. Involving some or all of the team in backlog grooming gives a degree of empowerment to the work they will and won’t work on incoming sprints. The outcome of this analysis simplifies the conversation with stakeholders who need to be told their idea will never be worked on. Instead of it being your opinion versus theirs, there is business and technical justification.
The PICK chart is a powerful tool in any Product Owner’s arsenal. By eliminating long wait times for features that will never be delivered, it ensures that internal stakeholders don’t waste time on false hopes. By ensuring work is delivered in each sprint, the team are seen to be continuously reducing risk and adding value to the product. Its visual nature and relative ranking in business and technical dimensions mean there are fewer heated arguments between teams, stakeholders and the Product Owner. It makes “the most difficult role” that little bit easier.
Related – 5 Tips For Building A CI/CD Pipeline
- K. Schwaber, J. Sutherland, The Scrum Guide, July 2016, [Online] http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf. [Accessed 6 June 2017]
- A. Johnson, The Most Difficult Role in Scrum: the Product Owner, April 2016, [Online] https://www.collaborativeleadershipteam.com/blog/2016/4/27/the-most-difficult-role-in-scrum-the-product-owner [Accessed 6 June 2017]
- A. Johnson, The Product Owner-the most difficult role in Scrum: Webinar Q&A, January 2016, [Online] https://www.watermarklearning.com/blog/product-owner-scrum-webinar/ [Accessed 6 June 2017]
- R. Pichler, Avoiding Common Product Owner Mistakes, February 2010, [Online] http://www.romanpichler.com/blog/avoiding-common-product-owner-mistake/ [Accessed 6 June 2017]
- Agile Alliance, INVEST Glossary Definition, [Online] https://www.agilealliance.org/glossary/invest [Accessed 6 June 2017]
- Agile Business Consortium, DSDM Atern Handbook, chapter 10: MoSCoW Prioritisation, 2008, https://www.agilebusiness.org/content/moscow-prioritisation-0 [Accessed 6 June 2017]
Header picture from http://www.tradingacademy.com
By Rob Healy, Principal Consultant at Ammeon