Definition: Assumptions are our best guess based on what we know today. They are also filled with risk. Your goal as Lean UX practitioners is to reduce risk. (1, pg 23)
Four Big Assumptions (1, pg 24)
Assumptions Workshop (1, pg 24-25)
Find out the following in reference to the problem statement
Analytics reports that show how the current product is being used
Usability reports that illustrate why customers are taking certain actions in your product
Information about past attempts to fix this issue and their successes and failures
Justification from the business as to how solving this problem will affect the company’s performance
Competitive analysis that show how your competition is tackling the same issue
I believe my customers have a need to:
These needs can be solved with:
My initial customers are (or will be):
The #1 value a customer wants to get our of my service is:
They can also get these additional benefits:
I will acquire the majority of my customers through:
I will make money by:
My primary competition in the market will be:
We will beat them due to:
My biggest product risk is:
We will solve this through:
We will know we are successful when we see the following changes in customer behaviour:
What other assumptions do we have that, if proven false, will cause our business/ project to fail:
Who is the user?
Where does our product fir in their work or life?
What problems does our product solve?
When and how is our product used?
What features are important?
How should our product look and behave?
Give everyone the worksheet and ask them to answer the assumption questions individually about the problem statement
Collect all the assumptions together
Use these assumptions to form hypotheses
Hypothesis Statement Format (1, pg 30)
We believe [this statement is true]. We will know we’re [right/wrong] when we see the following feedback from the market: [qualitative feedback] and/or [quantitative feedback] and/or [key performance indicator change]
(1, page 30)
Hypothesis Driven Development (2, pg 87)
helps Scrum Teams to frame hypotheses and experiments with thinking about what they are trying to achieve and how they will measure it
helps teams to be mindful of assumptions
We believe [doing this feature] for [these personas] will achieve [this outcome]. We will know that this is true when we see [this measurement] changed.
Value and Growth Hypotheses (3, pg 61)
Value hypothesis: tests whether product delivers value to a customer (experiment, not survey)
Growth hypothesis: tests how new customers will discover product/ service (find early adopters – people who need the product the most – they will be eager to feedback)
Experiment Stories (1, pg 127)
Hypothesis you’re testing or the thing you’re trying to learn
Tactic(s) for learning (e.g. interviews/ a/b testing)
Who will do the work
A level of effort estimate (e.g. story points)
We believe that asking new users MORE questions during registration will increase complete profiles.
Tactic: landing page test & customer interviews
Assigned to: UX, PDM
Hypothesis Creation Workshop (1, pg 32 – 43)
Must have a problem statement before this
Brainstorm small outcomes that will lead to the big outcome(s) in the problem statement (e.g. what behaviours will predict more downloads?)
Vote all together on priority (have a decider in the room if necessary)
Create a personas
Validate these personas
Create user outcome (assumption of what the user is trying to do)
E.g. How does our product or service get the user closer to a life goal or dream?
Brainstorm features to meet these user outcomes
Assemble what you have created in steps 1-4 into the hypothesis table (below)
Fill in the gaps in the table as you find them
Between 7 and 10 rows on the chart is a good starting point
Ensure that the hypothesis you create out of this focuses on 1 feature (multi-feature hypotheses are hard to test)
Existing product problem statement elements (1, pg 25)
The current goals of the product or system
The problem the business wants addressed (i.e. where the goals aren’t being met)
An explicit request for improvement that doesn’t dictate a specific solution
[Our service/ product] is intended to achieve [these goals].
We have observed that the product/ service isn't meeting [these goals] which is causing [this adverse effect] to our business.
How might we improve [service/ product] so that our customer are more successful based on [these measurable criteria]?
Template (1, pg 26)
New product problem statement elements (1, pg 27)
The current state of the market
The opportunity the business wants to exploit (i.e. where the current solutions are failing)
A strategic vision for a product or service to address the market gap
The current state of the [domain] has focused primarily on [customer segments, pain points, etc]
Our product/ service will address this gap by [vision/ strategy]
Our initial focus will be [this segment]Template (1, pg 27)
“The work to be performed in the Sprint is planned at the Sprint Planning” (1)
Definition:Sprint Planning is a meeting involving the entire Scrum Team to collaboratively decide what work will be taken up for the Sprint and how the work will be done (2, pg 27)
Length:Maximum of 8 hours for a one-month Sprint
Input: Product Backlog, Definition of Done, Retrospective Improvements, Team Capacity Planning, Impediments, Product Increment
Outcome: Sprint Goal (The What) and Sprint Backlog (The Why)
People: Product Owner, Scrum Master, Development Team
By the end of the Sprint Planning, the Development Team should be able to explain to the Product Owner and Scrum Master how it intends to work as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment. (1)
What can be done this Sprint?
Product Backlog Items
The Development Team forecasts the functionality that will be developed during the Sprint for the Product Owner’s objective
The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
The Sprint Goal
Definition:The Sprint Goal is an objective that will be met within the Sprint through the implementation of the Product Backlog, and it provides guidance to the Development Team on why it is building the Increment (1)
During Sprint Planning the Scrum Team also crafts a Sprint Goal
The Sprint Goal is one coherent function
The Sprint Goal means all the Development Team work together rather than on separates objectives
The Sprint Backlog items can be negotiated with the Product Owner whilst the Sprint Goal
How will the chosen work get done?
The Development team decides how it will deliver the selected Product Backlog Items for the Sprint
The Development Team designs the system and the work needed to convert the Product Backlog Items into an Increment
Just enough to forecast what it can do in the Sprint
Work for the first few days of the Sprint is broken down more
Work may be of varying size, or estimated effort
The Product Owner helps to clarify and negotiate the selected Product Backlog items
The Development Team may also invite people with specific expertise to support them