TL; DR: Your Unfit Product Goal and the Product Goal Canvas
We plan a lot in Scrum: There is a daily plan when the Developers think about progressing toward the Sprint Goal during the Daily Scrum. Of course, the Sprint Goal reflects an intermediate target the Scrum team considers valuable to solve their customers’ problems. Moreover, there is the Product Goal, a mid- or long-term objective of the Scrum team.
The problem is that when Scrum teams already struggle with embracing the concept of the Sprint Goal—first, you agree on the objective of the Sprint, then you pick the work you consider necessary to accomplish it—they most likely also struggle with proper Product Goals.
Let’s check three critical issues Scrum teams have with Product Goals and a practical tool that helps you avoid the mess.
🇩🇪 Zur deutschsprachigen Version des Artikels: Das Problem mit dem Produkt-Ziel und der Product Goal Canvas — Making Your Scrum Work (28).
🗞 Shall I notify you about articles like this one? Awesome! You can sign up here for the ‘Food for Agile Thought’ newsletter and join 36,000-plus other subscribers.
🎓 Join Stefan in one of his upcoming Professional Scrum training classes!
📈 Let Us Create Transparency—join 975-plus peers: Join the Anonymous Scrum Master Salary Report 2023.
The Scrum Guide on the Product Goal
The Scrum Guide barely delves into the concept of the Product Goal, stating that “[It] describes a future state of the product which can serve as a target for the Scrum Team to plan against. The Product Goal is in the Product Backlog. ” (Source.) (The Product Goal is the commitment to the Product Backlog, providing transparency.)
Also, the Product Owner is tasked with “developing and explicitly communicating the Product Goal” as part of their Product Backlog management activities. (Source.)
No further guidance on the Product Goal is available from the Scrum Guide.
Product Goal Anti-Patterns
Given the Scrum Guide’s brevity on the Product Goal, there are three common Product Goal anti-patterns to observe:
No Product Goal: There is no Product Goal, or, even worse, the content of the Product Backlog is retroactively squeezed under a made-up “Product Goal,” as the Scrum Guide mandates the Product Owner to define one. This approach extends the bad habit of first picking the work of the Sprint and then figuring a Sprint Goal that covers most of the work. Again, from a holistic perspective, turning a core part of Scrum’s process upside-down does not help maximize the value of the work of the Scrum team members; it is merely a form of cargo-cult Scrum.
Par Ordre du Mufti: The Product Owner decrees Product Goals in a solitary act, excluding the rest of the Scrum team from the process. This behavior is highly problematic regarding mitigating the risk of a Product Owner falling in love with their solution over the customers’ problems. Therefore, their teammates should provide feedback and expertise to the Product Owner as early as possible, particularly on technical aspects and the Product Owner’s perception of what is valueable to their customers.
No Inspection: The opportunity to inspect progress toward the Product Goal during Sprint Review sessions is ignored. Practically, the Product Goal is never inspected or adapted until its completion or abandonment. Many humans crave continuity and routine. However, neglecting one of the four values of the Manifesto for Agile Software Development, here: responding to change over following a plan (Source.), undermines why the team chose Scrum in the first place: solving complex, adaptive problems while mitigating risk.
How to Remedy Product Goal Anti-Patterns
While the Product Owner is responsible for creating and communicating the Product Goal, it is beneficial to include the rest of the Scrum team in the process, similar to other Product Backlog management tasks. Again, this collaborative approach aims to foster a shared understanding among all Scrum team members about the Why, What, and How of the team’s journey. Also, it reduces the risk of creating technical risk due to a lack of understanding on the Product Owner’s side.
In this regard, Ralph Jocham developed and shared a valuable free alignment tool: the Product Goal Canvas.
Depending on your preliminary work, the time to create the first version of the canvas will vary. For example, if you have already invested in maintaining a Business Model Canvas and know your stakeholders well, it may take 60-90 minutes. On the other hand, it will take much longer if you haven’t done any preliminary work on the product and business side.
Once you create the first version, please regularly inspect and adapt your Product Goal Canvas for as long as you work on the respective Product Goal.
License: Creative Commons, Attribution-NonCommercial-ShareAlike 2.0 Generic (CC BY-NC-SA 2.0).
Take the Product Goal to the Scrum team. No matter that the Product Owner has the final say in defining the Product Goal, it is beneficial to include all Scrum team members in creating the Product Goal to avoid introducing unnecessary technical risk through the backdoor or heading in the wrong direction as a Scrum team. The Product Goal Canvas is one tool that can structure this alignment process.
How are you creating Product Goals? Please share your findings with us in the comments.
📖 The Product Goal — Related Posts
✋ Learn More About the Product Goal — Join the 12,000-plus Strong ‘Hands-on Agile’ Slack Community
I invite you to join the “Hands-on Agile” Slack Community and enjoy the benefits of a fast-growing, vibrant community of agile practitioners from around the world.
If you like to join all you have to do now is provide your credentials via this Google form, and I will sign you up. By the way, it’s free.
The article Your Unfit Product Goal and the Product Goal Canvas — Making Your Scrum Work (28) first appeared on Age-of-Product.com.