Scrum framework : creating Value

Creating Value

• Questions
  • Are you building the right thing to create value for the organization?
  • How do you know?
• Product Value dimension
  • If you are not asking these two questions regularly, you might be missing the product value dimension.
• Product
  • The product is the purpose of what you are doing.
  • It is why you create teams.
  • The product is why you do Scrum.  
• Product Value
  • Therefore, you must focus on understanding and growing Product Value.

Scrum Mastery : optimize Product Value

• Scrum Mastery: 4 Steps to Optimize Product Value : https://www.scrum.org/resources/blog/scrum-mastery-4-steps-optimize-product-value
  • 4 steps
    • Step 1: Foster a Product Mindset (over a project mindset)
    • Step 2: Paint the Bigger Picture
    • Step 3: Enable Value Emergence
    • Step 4: Validate Actual Value
  • Value
    • Now you have the building blocks in place, so you can measure actual value.
    • Value is just an assumption until validated by the market, so the faster you release, the faster you learn (Lean Startup). 

Step 1 : Foster a Product Mindset over a Project Mindset

• Product mindset
  • 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.
• Project mindset
  • As a Project Management Professional (PMP) who started my career in traditional project management, I am very familiar with the Project Mindset.
• Success ?
  • The measure of success is usually based on the iron triangle: delivering all defined scope on time and on budget.
  • Scrum
    • Scrum is not about delivering more things faster and cheaper.
    • Scrum is about delivering higher value more frequently.
  • Risk
    • And by doing this, you reduce risk to the organization and tap into the art of the possible.
  • Budget and Schedule
    • While budgets and schedules still serve a purpose, you need to place more emphasis on ensuring you are building the right things.

Product Mindset

• Ensure you are building the right things, the right Product.
  • 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 :
  • How are we validating assumptions about the User needs/ the market demand?
  • What are we learning about value?
  • How is this guiding our Product decisions?
  • What has changed with our Users/ our competitive environment since we began this initiative?
  • Product Owner responsability
• A Product Owner plays an important role in fostering this Product Mindset within the Scrum Team and the Organization.

Step 2 : Paint the Bigger Picture

• Big picture
  • 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.
• Product Vision
  • 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.
• Value
  • 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.
  • Examples
    • While this is highly dependent on context, consider these examples of types of value.
    • Business goals (e.g. customer conversion rate)
    • Profit/ revenue (e.g. revenue per customer, repeat customers)
    • Cost savings (e.g. customer acquisition cost, cost/ customer)
    • Customer/ user growth (e.g. new customers, market share, customers using latest release)
    • Feature usage (e.g. customers using a feature, time spent using feature)
  • Now get specific with defining value statements and how you will measure value.

Step 3: Enable Value Emergence

• Problems and Solutions
  • Solutions to complex problems will emerge as you do the work (not just by analyzing and talking about the work).
  • Examples
    • You could learn that assumptions were wrong.
    • You could see that the market or even the business model has changed.
• Product Backlog
  • So you must enable value to emerge as you build the product.
  • The Product Backlog represents what you plan to build and the order in which you plan to build it.
• Product Backlog refinement
  • There are 3 things to focus on to enable value emergence through your Product Backlog refinement process.
    • Break things down smaller
    • Understanding of value alignment
    • Zoom out/ zoom in
  • Break things down smaller… for more flexibility in how quickly you can deliver value.
• Building the Product Backlog
  • Vision
    • 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.
    • Then you can identify the key features, functions, or capabilities expected to deliver those desired outcomes.
  • Small is beautiful
    • 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.
  • Value alignment
    • Create an understanding of value alignment … to deliver greater value.
  • Product Backlog Items (PBIs)
    • 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.
  • PBIs, US and metadata
    • 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.
  • PBIs and ROI
    • Perhaps it is a ROI dollar amount.
  • PBIs and Value proposition
    • Perhaps it is a mapping to a value proposition you defined as part of Step 2.
  • Zooming
    • Zoom out and zoom in repeatedly… to ensure you are still on track for value delivery.
      • Inspect and Adapt
        • 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
        • Now you have the building blocks in place, so you can measure actual value.
        • Release
        • 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
        • Developers can often help come up with ways to build data gathering capabilities into the product.  
        • Data
        • As a product grows in size and complexity, you will need to grow your processes and tools to gather this empirical data.
        • Analyzing the 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.
        • Analyzing the trends
        • 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.)
        • Transparency
        • Make actual value measures transparent.  
        • Sprint Review and Feedbacks
        • Get input from stakeholders and how they think trends should inform adaptation.  
        • A Sprint Review is a great opportunity to do this.
      • Caution !
        • 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.

Step 4 : Validate Actual Value

• Now you have the building blocks in place, so you can measure actual value.
• Release
  • 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.
• Questions
  • What is the the actual value realized versus the desired value ?  
  • How will you gather this empirical data in an effective way ?
• Developers
  • Developers can often help come up with ways to build data gathering capabilities into the product.  
• Data
  • As a product grows in size and complexity, you will need to grow your processes and tools to gather this empirical data.
  • Analyzing the Data
  • Once you have the data, you can analyze the trends.
  • Remember that one data point in time doesn’t tell you much.  
• Data and Trends
  • 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.
  • Analyzing the trends
  • 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.)
• Transparency
  • Make actual value measures transparent.  
  • Sprint Review and Feedbacks
    • Get input from Stakeholders and how they think trends should inform adaptation.  
    • A Sprint Review is a great opportunity to do this.

In summary

• Questions
  • Are you building the right thing to create value for the organization?
  • And how do you know?
• Empiricism
  • Empiricism guides you in fiercely tackling these difficult product value questions.
• Transparency
  • 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.  
• Complexity
  • Just like the complexity and unpredictability inherent in building a working product, there is complexity and unpredictability in figuring out what to build.
• Decisions
  • You will learn by doing and making decisions based on what is known.
• Value
  • 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 releasable product.
• Learning
  • 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 :

• 4 Dimensions for Scrum Mastery
• Scrum Mastery: 5 Steps to Grow a Strong Team Identity
• Scrum Mastery: 5 Steps to Improve Team Process
• Scrum Mastery: 4 Steps to Optimize Product Value
• Scrum Mastery: 5 Steps to Leverage the Organization

Empathy Driven Development : Rescuing Value From the Bermuda Triangle

• The Elements of Value
  • Outcome Mapping & Scrum: The Story of Amazing Decisions
• The Professional Scrum Product Owner Book : https://www.scrum.org/resources/professional-scrum-product-owner-book
  • Product ownership is about more than mechanics: it’s about taking accountability and focusing on value in everything you do.
  • In The Professional Product Owner, two leading experts in Scrum product ownership show how to identify, measure, and maximize value throughout your entire product lifecycle.

Go to success

• Success
  • Define success from the “outside in,” using external measurements to guide development
• Empowerment and Entrepreneurship
  • Bring empowerment and entrepreneurship to the Product Owner’s role, and align everyone behind a shared business model
• Scrum framework
  • Effectively apply Scrum’s Product Owner role, artifacts, and events
• Just In Time
  • Populate and manage Product Backlogs, and use just-in-time specifications
• Transparency and Technical Debt
  • Improve transparency, reduce technical debt, and scale your product (not your Scrum)
• Autonomy
  • Use Scrum to inject autonomy, mastery, and purpose into your product team’s work

Versioning

• Created on 01/05, 2023.
• Updated : 01/16, 2023.