This is the fourth in a series of posts exploring Scrum Mastery. In our first post, we introduced the four dimensions of Scrum Mastery: Team Identity, Team Process, Product Value, and the Organization. In this post, we will explore the product value dimension.
Are you building the right thing to create value for the organization? How do you know?
If you are not asking these two questions regularly, you might be missing the product value dimension.
The product is the purpose of what you are doing. It is why you create teams. The product is why you do Scrum. Therefore, you must focus on understanding and growing product value.
Photo by NeONBRAND on Unsplash
A product mindset is about focusing on creating valuable outcomes.
Output doesn’t matter if you are building things people don’t want or won’t use.
As a Project Management Professional (PMP) who started my career in traditional project management, I am very familiar with the project mindset. The measure of success is usually based on a misunderstanding of the Iron Triangle: delivering all defined scope on time and on budget.
Scrum is not about delivering more things faster and cheaper.
Scrum is about delivering higher value more frequently.
And by doing this, you reduce risk to the organization and tap into the art of the possible.
While budgets and schedules still serve a purpose, you need to place more emphasis on ensuring you are building the right things. The next steps will provide details on how to do this. However, you always need to be doing the work of fostering a product mindset. It is very easy to slip back into old ways of thinking, especially under pressure.
When conversations come up about “project status,” listen for the mindset driving the dialogue. If it is just about percent complete, red/ yellow/ green, and issue tracking, ask some powerful questions that bring focus to the product mindset. Here are just a few examples:
A Product Owner plays an important role in fostering this product mindset within the Scrum Team and the organization.
Since you are building iteratively and incrementally, it is essential to have a clear idea about the bigger picture of what you are working towards and why. This helps determine if you are still in alignment and informs adaptations needed.
There are many techniques to help clarify what the product is trying to achieve (product vision), and the business model behind it. A product vision communicates what you desire this product to be and for whom. It speaks to the target customer and the primary value proposition provided to that customer.
The bigger picture also includes defining value. There will be many features and functions desired. In order to make decisions about what is more valuable or less valuable, you must define the most important facets of value for the product and how you will know that you achieved the desired value.
While this is highly dependent on context, consider these examples of types of value.
Now get specific with defining value statements and how you will measure value.
Solutions to complex problems will emerge as you do the work (not just by analyzing and talking about the work). You could learn that assumptions were wrong. You could see that the market or even the business model has changed.
So you must enable value to emerge as you build the product. The Product Backlog represents your current Product Goal, what you plan to build and the order in which you plan to build it. There are 3 things to focus on to enable value emergence through your Product Backlog refinement process.
Break things down smaller… for more flexibility in how quickly you can deliver value.
Once the vision is established, there are some practical approaches to build out the next level of detail. You can start by identifying key business outcomes or goals on the path towards the vision. This will help you identify a clear Product Goal to create focus and enable greater transparency. Then you can identify the key features, functions, or capabilities expected to deliver those desired outcomes.
The smaller you break things down, the more flexibility you have and the faster you can deliver value and validate assumptions. There are many complementary practices and concepts to help you focus on smaller pieces (e.g. Story Mapping, Assumptions Mapping). Once you have the “mid-size level”, consider exploring patterns for splitting Product Backlog items (PBIs) even further.
And remember you don’t need to break everything down up front. Your Product Backlog emerges over time, and you will adapt it based on what you are learning as you build the product iteratively and incrementally.
Create an understanding of value alignment … to deliver greater value.
Another way to create focus on value in your Product Backlog is to identify the desired outcomes. Many times Product Backlog items (PBIs) state the features and functions desired. But what if we switched this to focus more on the desired outcomes for the feature or function.
There are many techniques to focus PBIs on value, including user stories (if you use them well), hypothesis driven development, and A/B tests, just to name a few. You can also simply capture value as metadata in your Product Backlog for each PBI. Perhaps it is a ROI dollar amount. Perhaps it is a mapping to a value proposition you defined as part of Step 2.
Zoom out and zoom in repeatedly… to ensure you are still on track for value delivery.
As you inspect and adapt, you need to “zoom out” to see what’s different, then “zoom in” again to see what’s different now and how you may need to adapt. This is how you validate learning and then apply that learning as the path unfolds before you. The frequency of your zoom in/ zoom out will depend on your product, how frequently you are able to validate assumptions in the market, and how much change you experience in your business and market.
Note: Product Owners are not expected to determine what is valuable in isolation. Nor are they expected to know the best way to break down value into smaller, clearer pieces and perfectly capture it in writing for everyone’s understanding. This is why Product Owners must leverage techniques and skills that engage and enable others to collaborate in the process of Product Backlog refinement.
Now you have the building blocks in place, so you can measure actual value.
Value is just an assumption until validated by the market.
You need to release in order to get the most accurate picture of actual value delivered. Seek empirical data to create the transparency needed for informed decision-making.
What is the the actual value realized versus the desired value? How will you gather this empirical data in an effective way?
Developers can often help come up with ways to build data gathering capabilities into the product. As a product grows in size and complexity, you will need to grow your processes and tools to gather this empirical data.
Once you have the data, you can analyze the trends. Remember that one data point in time doesn’t tell you much. The trends are what matter. And you need multiple types of data because one type of data doesn’t tell you the full story, since there are often many factors (some beyond your control) that can affect the use of your product.
As you are analyzing the value trends, consider what changes you released and when and how those may have impacted value. Consider what factors are beyond your control (e.g. a decline in the stock market could impact user decisions even though you’ve implemented new features you expected to increase sales.)
Make actual value measures transparent. Get input from stakeholders and how they think trends should inform adaptation. A Sprint Review is a great opportunity to do this.
Are you building the right thing to create value for the organization? And how do you know?
Empiricism guides you in fiercely tackling these difficult product value questions. You must have transparency to value, and you must have frequent enough inspection of the actual value realized so that you can adapt as needed. Just like the complexity and unpredictability inherent in building a working product, there is complexity and unpredictability in figuring out what to build. You will learn by doing and making decisions based on what is known.
Scrum is not about how much stuff we build. Scrum is about how much value we can create for the organization through frequent delivery of usable product. Therefore, Scrum is also about continuously learning and adapting in order to wring more value out of the product.
Read all posts in this series:
___________________________
Want to take your learning deeper?
If you enjoyed this post, check out my book Mastering Professional Scrum.
This book illuminates what it means to effectively apply empiricism, an agile mindset, and teamwork to truly unlock the benefits of agility.
AGILE SOCKS is a registered trademark of Agile Socks LLC. Other marks used herein are the property of their respective owners. For more information see Trademark Notice in Terms & Conditions.