Dozens of individuals receive training to become Certified Scrum Product Owners at our public learning events in Toronto, Ontario.
What is a Product Owner? And how do they create a product vision in alignment with the team they work with? Xi Zeng, over at 3 Agile Guys blog, has some ideas worth sharing.
Here is an excerpt from his article on product vision.
How can a product vision help you?
A project always has a predefined scope and goals, therefore defining a vision for a project is in most of the cases not really necessary. A product has usually a much bigger scope and a longer life cycle, so it’s important to create a product vision in advance in order to:
help the business define requirements
be able to evaluate the value of the project
simplify the communication among the organisation (or with clients)
act as project’s compass
support the prioritization and decision-making in projects
The vision should consider the long term life cycle of the product and should not be easily reachable. Define even a vision that is almost impossible to reach. All short term goals should be clear defined and measurable, e.g. what is the next step in the project, next valuable goal, how to prioritize work items in backlog, etc. But the vision represents the long term future, it should stay ambitious. Just like when you’re hiking on the mountains, you can see the rocks under your feet, you know their size and form, you can touch them and even pick them up. But you can only see roughly where is the top of the mountain. While hiking, reaching the top of the mountain is our vision.
I think there is a lot of value in what Xi writes and it is worth exploring in greater depth.
Regular big up-front planning is not necessary with Scrum. Instead, a team can just get started and use constant feedback in the Sprint Review to adjust it’s plans. Even the Product Backlog can be created after the first Sprint has started. All that is really necessary to get started is a Scrum Team, a product vision, and a decision on Sprint length. In this extreme case, the Scrum Team itself would decide what to build in its first Sprint and use the time of the Sprint to also prepare some initial Product Backlog Items. Then, the first Sprint Review would allow stakeholders to provide feedback and further develop the Product Backlog. The empirical nature of Scrum could even allow the Product Owner to emerge from the business stakeholders, rather than being assigned to the team right from the start.
Starting a Sprint without a Product Backlog is not easy, but it can be done. The team has to know at least a little about the business, and there should be some (possibly informal) project or product charter that they are aware of. The team uses this super basic information and decides on their own what to build in their first Sprint. Again, the focus should be on getting something that can be demoed (and potentially shippable). The team is likely to build some good stuff and some things that are completely wrong… but the point is to get the Inspect and Adapt cycle started as quickly as possible. Which means of course that they need to have stakeholders (customers, users) actually attend the demo at the end of the Sprint. The Product Owner may or may not even be involved in this first Sprint.
One important reason this is sometimes a good approach is the culture of “analysis paralysis” that exists in some organizations. In this situation, an organization is unable to do anything because they are so concerned about getting things right. Scrum is a framework for inspect and adapt and that can (and does) include the Product Backlog. Is it better for a team to sit idle while someone tries to do sufficient preparation? Or is it better to get started and inspect and adapt? This is actually a philosophical question (as well as a practical question). The mindset and philosophy of the Agile Manifesto and Scrum is that trying to produce valuable software is more important that documentation… that individuals and how they work together is more important than rigidly following a process or tool. I will agree that in many cases it is acceptable to do some up-front work, but it should be minimized, particularly when it is preventing people from starting to deliver value. The case of a team getting started without a product backlog is rare… but it can be a great way for a team to help an organization overcome analysis paralysis.
The Agile Manifesto is very clear: “The BEST architectures, requirements and designs emerge out of self-organizing teams.” [Emphasis added.]
Hugely memorable for me is the story that Ken Schwaber told in the CSM course that I took from him in 2003. This is a paraphrase of that story:
I [Ken Schwaber] was talking to the CIO of a large IT organization. The CIO told me that his projects last twelve to eighteen months and at the end, he doesn’t get what he needs. I told him, “Scrum can give you what you don’t need in a month.”
I experienced this myself in a profound way just a couple years into my career as an Agile coach and trainer. I was working with a department of a large technology organization. They had over one hundred people who had been working on Agile pilot projects. The department was responsible for a major product and executive management had approved a complete re-write. The product managers and Product Owners had done a lot of work to prepare a product backlog (about 400 items!) that represented all the existing functionality of the product that needed to be re-written. But, the big question, “what new technology platform do we use for the re-write?” had not yet been resolved. The small team of architects were tasked with making this decision. But they got stuck. They got stuck for three months. Finally, the director of the department, who had learned to trust my advice in other circumstances, asked me, “does Scrum have any techniques for making these kind of architectural decisions?”
I said, “yes, but you probably won’t like what Scrum recommends!”
She said, “actually, we’re pretty desperate. I’ve got over a hundred people effectively sitting idle for the last three months. What does Scrum recommend?”
“Just start. Let the teams figure out the platform as they try to implement functionality.”
She thought for a few seconds. Finally she said, “okay. Come by this Monday and help me launch our first Sprint.”
The amazing thing was that the teams didn’t lynch me when on Monday she announced that “our Agile consultant says we don’t need to know our platform in order to get started.”
The first Sprint (two weeks long) was pretty chaotic. But, with some coaching and active support of management, they actually delivered a working increment of their product. And decided on the platform to use for the rest of the two-year project.
You must trust your team.
If your organization is spending more than a few days preparing for the start of a project, it is probably suffering from this pitfall. This is the source of great waste and lost opportunity. Use Scrum to rapidly converge on the correct solutions to your business problems instead of wasting person-years of time on analysis and planning. We can help with training and coaching to give you the tools to start fast using Scrum and to fix your Scrum implementation.
The Product Owner Simulation that I shared last summer has some minor updates based on a stronger emphasis on product vision. In particular, two 5 minute exercises before and after the Product Box exercise help to frame the concept of product vision and make it stronger.
This Product Owner Simulation exercise rests on the idea that people learn a lot better by doing something than by talking about it. My Product Owner classes were getting great reviews, but I really felt like there was something missing compared to my ScrumMaster classes which have a full-day ScrumMaster simulation exercise. It took a little while to figure it out, but this article describes in detail how I do the simulation for the Product Owner class. I’m sure it will evolve and get refined from here since I have only used the simulation twice so far.
UPDATE: 2016-08-14 – major updates to the Product Owner Simulation after having used it at least 15 times since this was originally written!
UPDATE: 2017-07-13 – minor updates including new versions of handouts that better explain some concepts, and slightly expanded facilitator’s notes.
NOTE: Permission to use this exercise / print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
Pre-requisites: None! No prior Scrum or Agile knowledge or experience required. However, it is recommended that participants have an introduction to Scrum or have read the Scrum Guide.
Audience: Product Owners, Business Analysts, Project Managers, Product Managers and other people responsible for business results and who interact with a Scrum team.
Timing: This simulation takes at least 7 classroom hours. I usually run it from 8:30am to 5:00pm with a one hour lunch break and two 15 minute breaks during the day.
Planning Game cards (email me if you want a bunch for free!)
Room Setup: Round tables with 5 to 7 chairs at each table. Materials distributed to each table.
Product Owner Simulation Agenda
(with facilitator’s notes in red)
Introduction to the Product Owner Simulation
Lecture: Simulation Overview, Backlog Preparation and Refinement The purpose of the overall simulation is to learn to create a good Product Backlog in preparation for a Scrum team’s first Sprint. Many of the techniques we explore will also be useable in ongoing Product Backlog Refinement. Review the agenda with participants.
Exercise: Great Products and their Vision 5 minutes – at table groups, think about the physical consumer products you know and use often. How are those products marketed and sold? How are they presented? How do you decide to use that product vs. a competitive product? Make sure you discuss specific products rather than corporate brands or product categories.
Discussion: What Makes a Great Product Vision? Ask for the group to brainstorm the qualities of a great product vision. Ensure that “simplicity”, “urgency”, and “emotion” are all mentioned. (Great reference: “Made to Stick: Why Some Ideas Survive and Others Die” by Chip and Dan Heath.)
Discussion: Choosing a Product for the Simulation Give participants three product options (suggested options: “Doggy dating web site”, “iPad app for plastic surgeons’ medical and practice management”, “POS for food trucks with social features”). A table group must agree to one of the options. They will stick with this product for the remainder of the simulation. Three minutes to decide.
Product Vision
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Exercise: Product Vision Statement
5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”. The audience of the product vision statement is your Scrum Team (NOT customers). Debrief by hearing from each group, then asking if the three characteristics have been communicated.
Lecture: Explain the Product Vision handout and ask for questions, insights. At this time, highlight the differences between a “product” and a “project”. Emphasize the concept that a product has customers who pay money and who have choice about what they buy, and that those customers are outside of your organization. Possible discussion about Scrum being ideally suited for Product Development vs. project management or operations.
Lecture: Product Box Talk about the need for a compelling vision as a pre-requisite for high-performance teams, and a way to decide what is in vs. out of a Product Backlog. Introduce “Product Box” as a way to do market research in an Agile compatible way (collaborative, light documentation, quick). Talk about the pattern of a product box: front to attract, back to showcase, sides to deal with objections. Use of online resources / web research is allowed but should not dominate the exercise.
Exercise: Building Your Product 30 minutes, with warnings at 15 minutes and 5 minutes remaining. Ensure that by 10 minutes in, the group has actually started using the craft supplies and isn’t just talking.
Exercise: Presenting Your Product 5 minutes – give additional time to allow groups to prepare for a trade show (in their market) presentation where other groups (or yourself) will role-play sceptical trade show participants.
Discussion: Debrief Product Box Focus on feasibility of using Product Box in real life, the power of metaphor, and the power of collaboration.
Exercise: Product Vision Statement Reprise 5 minutes – attempt to craft a brief, compelling product vision statement that communicates “simplicity”, “urgency” and “emotion”.
Discussion: Debrief by hearing new Product Vision Statements.
Product Users
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: User Categories Describe “users we sell”, “users who pay” and “admin users” as the three major categories. Users can be in hierarchies where a general user type may have two or more specific sub-types.
Exercise: Identifying Users 10 minutes. One user of each main type, at least 5 users in total. More is okay.
Lecture: Personas, Usability and Empathy Introduce Persona concept (great reference: “The Inmates are Running the Asylum” by Alan Cooper). Usability as part of Agile, not separate (i.e. “working software”). Identifying personas as a way to build empathy from the development team to the end users/customers.
Exercise: Generate a Persona 10 minutes. Choose a primary user. Generate name, age, background story, and relationship to product. Find an image from a stock photography site. Important: do at least a little bit of research and tie some part of your persona to that research! Try to be specific and write the background so it emphasizes the concept of empathy.
Business Value
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: Good and Bad Metrics Describe ROI, TTM and CSat as all-around good metrics. Explain red-yellow-green project dashboard and lines-of-code as bad metrics. Ask for other examples of good or bad metrics.
Exercise: Value Metrics 10 minutes. At table teams try to come up with at least 10 quantitative and 10 qualitative metrics. Use the handout as a worksheet. Focus on metrics relevant to the simulation product, but also consider metrics that might be from other businesses or viewpoints (e.g. finance metrics, marketing analytics, etc.).
Discussion: Value Metrics Throughout the classroom, share all the metrics and write them on a flip chart so they can all be seen at once. Ask for insights or questions about metrics.
Exercise: Key Metrics From the flipchart, each table team should choose 3 to 6 metrics that are most important to measure business success of their product. It’s okay for that short list to include ROI, TTM and CSat. Keep this list handy for the next part of the simulation.
Discussion: Metrics and Product Vision Discuss if/how Product Vision helped to choose the key metrics. If needed, allow a few moments for participants to reconsider the metrics they chose in light of their Product Vision.
Product Backlog Items
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Exercise: Create Product Backlog Items Use the product box, the user categories, and the business metrics. For each row in the worksheet, identify a feature, decide which user interacts with the product to exercise that feature, and choose the business metric that is most improved by implementing the feature. For each, decide if the feature is visible to the user through the user interface. The resulting worksheet should be filled up such that at least ten of the features are visible in the user interface.
Lecture: Writing Effective User Stories Use the example “As a Job Seeker, I can upload my resume, so that I get a job.” Explain the user story template based on the handout. Emphasize the idea of end user functionality. Explain user stories as an important tool, but optional part of Scrum. Usually some time is spent on a discussion about physical note cards vs. electronic tools – emphasize the fact that the note cards support the values and principles of the Agile Manifesto while electronic tools (typically) subvert them.
Exercise: Create User Stories Goal: 20 user stories for each group’s product, at least five user stories for the persona, and two user stories for each other type of user, all done in 20 minutes. User Stories must be written on 3×5 note cards with a 2cm blank area on right side of each card. The groups start by writing one or two User Stories together, then divide and conquer to create the rest. At the end of the 20 minutes, there is a brief amount of time allocated to making sure there are no duplicated “features” described.
Discussion: Review User Stories Workshop examples from each group. Ensure that the “benefit” section of each story does not contain a feature. Possibly discuss the three parts of a User Story as “who”, “what” and “why”. The benefit is usually related to time, money or happiness and connects the User Story to the product vision.
Exercise: Small, Uncertain, Large Effort Estimation Small means “easily and with certainty fits within a single Sprint”, large means “definitely requires more than a full Sprint of work”, and uncertain means either “uncertain size” or “uncertain if it will fit in a single Sprint”. Teams create buckets and sort all the user stories into the three buckets – they must role play being technical contributors (Development Team Members). Start by identifying one “small” one and one “large” one, then by dividing an conquering. Final step is to verify that the small ones really are small.
Lecture: Splitting User Stories Go through each of the “top” six splitting methods. Provide simple examples where the group needs help. E.g. error conditions as an example of splitting by business logic.
Exercise: Split Some Goal: result in at least 30 user stories, use each of the top six splitting methods at least once, give 15 minutes. Focus on splitting the items that were estimated in the “Large” or “Uncertain” buckets.
Discussion: Review Splitting
Estimation and Financial Modelling
Remind participants that in Scrum, we don’t necessarily do all the steps of the simulation in any particular order. Instead, we are practicing techniques that can come into use at various times. The Product Owner Simulation must be done in a particular order. The techniques are all part of the overall process of Product Backlog Refinement.
Lecture: Effort, Value and ROI Customers and business stakeholders estimate value, Scrum team members estimate effort, and ROI is the calculation of the ration of value over effort. Discuss examples of ordering based on these ratios, e.g. 8/2 vs. 8/4 and 200/20 vs. 20/2.
Lecture: The Bucket System Review process based on handout.
Exercise: Estimating Business Value 10 minutes. Goal: all user stories get a business value estimate written in the top right-hand corner of the user story card.
Exercise: Estimating Effort 20 minutes. Goal: estimate 3 user stories using the Planning Game. Use the Bucket System to estimate the remainder with the ones already estimated as the reference points.
Lecture: Ordering a Product Backlog Review ROI as a method to order the PBIs. Reminder that the Product Owner has final authority and can ignore the estimates in deciding on the order.
Exercise: Calculating ROI and Ordering 5 minutes. Just simple divide-and-conquer calculations of business value divided by effort for all the user stories.
Lecture: Simulation Wrap-Up – Where Does This Fit? Reminder of the idea of creating an initial Product Backlog that is “good enough” to start the first Sprint.
NOTE: Permission to use the Product Owner Simulation exercise and print associated materials is granted with a simple request: please link to this page on your blog, in a LinkedIn group or Google group, like it on Facebook etc. or write a comment in our comments section!
If you are interested in experiencing this Product Owner Simulation first-hand, please consider attending one of our Certified Scrum Product Owner learning events.
As a Team Member, it is my job to figure out how to solve a problem or request that is stated by a Product Backlog Item (PBI), with the help of my team. It is the responsibility of the Product Owner to give us the vision of the product and decide how much scope is to be done to satisfy the PBI. One simple way to think about this concept is that the Product Owner is responsible for the “what” and “why” and the Scrum Team is responsible for the “how” and “who”. If the Team Members decide on the product vision by themselves, they run the risk of misinterpreting features, moving down a path that is not valuable or even creating work disconnected from the needs of those who will be using the software. If the Team Members choose their own scope they may do much less than is needed or much more than is required. There is a balance in the Product Owner providing vision and scope, and the Scrum Team providing knowledge and experience in its execution.
The Product Backlog is a list of potential work to be done for future Sprints. This list is most vibrant when as many people as possible contribute to it. Those directly connected (stakeholders such as the Team Members, users of the systems, etc) have a stake in the product’s growth so they also have plenty of ideas that may benefit its value. Adding a Product Backlog Item (PBI) is like brainstorming where all ideas are welcome. Then it is the responsibility of the Product Owner through conversations with others to order the list based on the most value for the least effort (and sometimes to reject PBIs if they are too outside the product vision). If the creation of PBIs is limited to just a few individuals, or even just the Product Owner alone, it is likely that many great ideas will not surface and will be lost. Also by having all stakeholders contribute PBIs, the Product Owner builds collective ownership in the work of the Scrum Team which helps the team overcome obstacles and become supported by a larger group.
