Product Backlog

• an emergent, ordered list of what is needed to improve the product
• the single source of work undertaken by the Scrum Team
• 1 Product Backlog is used for multiple Scrum Teams working together on the same product
• PO Work with Ds on the PB to identify and create PBIs that will achieve Goal
• discuss the PBIs that are taken into the Sprint and also look for alternative ways to achieve the Sprint Goal
• Content:
  • Product Goal - Commitment of the Product Backlog
    • describes a future state of the product which can serve as a target for the ST to plan against
    • long-term objective they must fulfill (or abandon) one objective before taking on the next
  • PBI
    • emerges to define “what” will fulfill the Product Goal
    • Order, Description (Persona, Output, Outcome), Value, Estimation, (acceptance criteria, dependencies) ((ready, scope, risks, priority, Business Impact, Business Goal))
    • conversations that we will need to have in the future…
• Models:

  • Epic -> User Story

  • Outcome Mapping (technique to enhance PB transparency)

    • Deciding what’s the most valuable thing to do can be difficult
    • The transparency of the Product Backlog is key to facilitating decision making
      • An outcome map makes transparent the relationship between a goal, the players (Persona-WHO) contributing to that goal, their desired behaviors (outcomes) & the outputs created by ST
    • Outcome Mapping is a powerful technique to enhance Product Backlog transparency
      • focus on encouraging customer behavior that would lead to our goal
      • 1. We have a business outcome we want to achieve, think which outcome in the players (Persona-WHO) will help us to achieve such business goal, and then we think which features will help to the player (Persona-WHO) to achieve his outcome
      • 2. After define this player (Persona-WHO), look into how this player (Persona-WHO) will have to change their behavior to achieve the company’s goal
      • 3. An outcome is a change in behavior that leads to a goal
      • Focusing on outcomes is more likely to achieve goals than producing more outputs
      • 4. outputs are usually just assumptions of value. Like any assumption we need to see if it’s true, and so we should try to find out if building these outputs will actually lead to the outcomes we want
      • 5. we refine the outputs by adding details, estimates, assumed value and order
        • outputs with higher estimates or riskier assumptions, define experiments to run to test assumptions and avoid investing time into creating something that has no value
        • Outcome Map is like an iceberg that had the most valuable PBIs at its top and those with the lowest value at the bottom
    • most organizations set goals and immediately start their activities. without understanding how these activities connect to their goals, these organizations risk being busy without achieving their goal
    • Model:

    <aside> <img src="/icons/info-alternate_blue.svg" alt="/icons/info-alternate_blue.svg" width="40px" /> Goal-WHY: why we are doing this (will help achieve a BITG (Business Intermediate Tactical Goal)

    Persona-WHO: people who can support or hinder us from achieving our goal

    Outcomes-WHAT: gain/benefit/changes in the players’ behaviors so that they help us achieve our goal (will help achieve a CORE PERSON goal or INTERMEDIATE PERSON goal)

    Output-HOW: the activities that we believe we have to produce to create the desired outcomes

    • Measurements </aside>

  • See the evolution of this model, the Model: Extended Impact Mapping

The User Story Needs A Remodel. Here’s Why

• Summary
  • User Stories have become the standard way Agile teams capture requirements
  • User Stories were introduced almost 20 years ago as a part of XP (Extreme Programming)
  • A lot has changed and it’s time we upgrade how we define and communicate work for teams
  • Most teams are using user stories
    • to document requirements
    • to align expectations between stakeholders and the delivery team
    • But building features with the goal of satisfying SHs is not good enough anymore
    • We should be focused on satisfying the customer
  • The Biggest Lie in Product Development: they know everything up front
    • The lie product departments & stakeholders tell themselves
    • That getting a bunch of subject matter experts in a room will allow them to make intelligent priority and scope decisions
    • The problem here is that most of these decisions are gut instincts not grounded in facts
    • They are “I think”/“I feel” decisions
    • Worse yet, these decisions aren’t validated until they are implemented & deployed into production, this is a very long & expensive feedback loop
    • our current requirements processes assume we actually know the right features to build
    • Stats show that more than half of the features we build are rarely used
  • “Requirements”
    • Think of the word.” If something is a “requirement” it sounds like a fixed need
    • The statistics show most “requirements” are not used, therefore not necessary to the user
    • These “requirements” are just guesses, If it’s an educated guess, then it’s a hypothesis
    • we should change from thinking about “requirements” to about defining “hypotheses?”
• The Relationship Between OKR’s And Business Objectives
  • We still need to have some clear goal or target
  • Today our goals are defined in the form of scope or the largest “epic” and then broken down into smaller user stories. But again this assumes we know the answer
  • we could borrow from the OKR (Objectives and Key Results) world:
    • instead of defining the “epic”, we define the business “objective” we are trying to achieve
  • 1. One way to prioritize would be for us to identify all of the “assumptions” we are making about our customers, product, market, solution, etc
  • 2. We could examine the risk and impact of these assumptions and by looking at the riskiest assumptions, it might help us prioritize which hypothesis to prove first
  • 3. Once we have a defined objective, engage our team to brainstorm ideas on the best way the object can be achieved and these ideas could be defined as a set of hypotheses
• Agile Teams and Hypothesis Creation
  • We talk a lot in Agile about self-organizing teams, however, most of these teams are still focused mostly on how to best “deliver.” these teams should not only be focused on delivering
  • also engaged in understanding the problem domain and creating hypotheses around solutions
  • We don’t want the PO and SH just throwing requirements over a wall for teams to implement
  • We have promoted story decomposition techniques for years so that we can deliver iteratively
  • But too often we still wait until we have a full solution before we deploy to production and get real feedback from the market
  • How could we learn faster?
  • What if we could run small “experiments” to prove our hypothesis or validate our assumptions without having to build the whole solution?
  • what is the smallest “experiment” that can be run to learn more about the problem or solution?
  • Most importantly learning that can be validated by our customers, not stakeholders
  • The emphasis of this approach would be to validate or invalidate our ideas as fast as possible
• NOTE: What is the difference between a hypothesis and an assumption?
  • Hypothesis
    • Something that has yet not been proved to classify as a theory but believed to be true
    • is tested explicitly by an experiment
      • In order to test if an assumption is true or not, one should develop a sound hypothesis (one or many) relevant to the assumption and the business problem
  • Assumption
    • is any statement that is believed to be true
    • is tested implicitly by an experiment
      • is a general feeling about a business problem
  • making them explicit, increase the clarity of the approach & the chance for learning
  • The two most important assumptions entrepreneurs make are
    • The value hypothesis
      • tests if a product/service really delivers value to customers once they are using it
    • the growth hypothesis
      • tests how new customers will discover a product/service
  • As soon as we formulate a hypothesis that to test, the DT should be engineered to design and run this experiment as quickly as possible, using the smallest batch size that will get the job done
• Model: book Lean UX, a different format from the typical user story for capturing PBIs:
  • We believe that we will achieve [business outcome] if this user [persona] can achieve [user outcome] with this feature [feature]
  • The important difference: belief is made explicit, as is the business outcome that will be achieved when the user has a particular experience
  • What’s missing from this statement, is how you will measure the user outcome