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)
Towards the end of 2018 I went to a workshop at Agile Leicester on Behaviour Driven Development (BDD) and Three Amigos. This article gives some references about where you can learn more about these techniques and then continues through the introduction of this technique to a team and the results that were achieved. I gave a talk back to the Agile Leicester community on this subject in early 2019 and the picture above is of that talk.
The stories we were using were closer to contracts than stories
I went to a workshop about BDD and Three Amigos at Agile Leicester given by Stuart Day.
We were keen on using the brilliant minds of all the team members to create the vision and to be a part of creating the solution rather than developing exactly what was written.
Our stories had lengthy acceptance criteria that weren’t focused on the user needs and stipulated exactly what the solution should be leaving no space for creativity.
There was not enough room to question, influence, and negotiate in the stories.
By using BDD and three amigos we would:
Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value
This would support us in negotiating and sharing solution ideas, moving away from it being pre-decided
Spread the understanding of the story through the team and enable empowerment
This would allow the team to make decisions on the solution with the Product Owner
In depth behaviour discussions would enable pragmatic approach to MVPe
This would allow us to deliver smaller increments of working software to allow feedback
To achieve our hypotheses we had to change how we worked.
First thing to change was how we wrote stories. I worked with our Product Owner to refocus the stories back on what the User wanted and only that. No more design specifications, no more interaction specifications that a user doesn’t need to gain the value. We stripped them right back to CARD and CONFIRMATION all from the user’s point of view. (see Ron Jeffries explain CARD, CONFIRMATION, and CONVERSATION here)
We changed how we talked through stories as a team. We previously had backlog refinement where the Product Owner would present to the team the stories and then we would move on when everyone understood.
We started with four hour-long Three Amigos sessions per sprint to refine the stories ready for the next sprint.
The team would decide who turned up from each specialty (i.e. who for the QA amigo and who for the Developer amigo) and the Product Owner would always be there, sometimes with a stakeholder if it made sense.
We used the acceptance criteria as a guide to writing the scenarios as Stuart demonstrated in his talk. We talked through each user-driven acceptance criteria and created all the behaviour scenarios that supported that confirmation.
1 – Focus our communications on the value to a user of a feature and the behaviours that would help us ultimately achieve that value
Changing how we wrote the stories brought the focus back to WHY we were developing the story in the first place and the unnecessary words were removed
Our Product Owner has felt that these discussions help to marry the user need and the technical depth behind the behaviours
Originally this did take up more time for her as instead of just writing her story and presenting it out to the team she had to spend time creating it with the team
But previously a change to a story would be very time-consuming and this made it more tempting to resist the change. Now change happened naturally
Overall, time was saved
2 – Spread the understanding of the story through the team and enable empowerment
Collaboration with people of all different disciplines shone a light on different options and things that previously may not have been thought of
For example a QA amigo may think about all broader scenarios like ‘what should the behaviour be if…’
A developer amigo might be able to see that a solution is going to be slow and take a lot of power to achieve
Existing behaviour was talked through to share knowledge of the product in general
When we started using BDD we only talked through the behaviour that would change with this story
We learned that omitting existing behaviour from our discussions was not the best approach as the team members who hadn’t touched that part of the product before didn’t know how this new story would impact what was already there
If we felt that the existing behaviour was something we needed to consider as part of the story then we created scenarios
Talking through the language in the scenarios all together boosted our shared understanding
We had plenty of conversations about what certain words meant to make sure we were all using common language
We used our user roles to make the scenarios relatable, defined terms, and debated grammar
Some of this was too far admittedly and one of the things we learnt is to not waste time straying from the goal of three amigos on a quest for perfection
3 – In depth behaviour discussions would enable pragmatic approach to MVPe
By splitting stories into scenarios we could see a bit clearer on their size
For example if we found one had a lot of scenarios we could group them together and there our story was split by functionality just as simple as that.
Or we could cut some out that maybe weren’t vital to the user. These scenarios could come later.
We did also learn that BDD scenarios don’t work for all types of features for example one with a specific, non-negotiable set of rules set by a regulator. Scenarios are good for in general what happens if a rule is followed or broken but not needed for the actual rules.
All in all using BDD and Three Amigos achieved the three hypotheses that we set out to achieve. There are many more benefits cited from using this technique, including improvements to quality and documentation, but as we weren’t measuring ourselves against them I haven’t included it in this article.
It also goes to prove that Agile community events are wonderful places to learn and I am extremely grateful for them (hence the cheesy slide of my thanks in the header picture).
To keep working with and improving. Will update with any new challenges or tips. Let me know how you have found using BDD and Three Amigos in the comments below.
Each team doing their own end of iteration/ release reviews.
Unsure approach from teams – especially those who had worked on features they didn’t feel have a ‘wow’ factor
Some team members said they felt they had already completed a review of their work for iteration or release and were not confident any further review would be
Each team having a ‘stall’ at the Science Fair (we had 6 teams in total holding stalls)
Stalls set out around the edges of the room with enough space for people to wander about and stand around each stall
Inviting all stakeholders from all teams and some in-business users
A number of rounds of ten minutes each were set up to allow the teams to also rotate and see each other’s stalls
An introduction was created to explain the format and summarise the features delivered in the interval length agreed
Notes from Setup
We took the idea to schedule these at regular intervals that suited the iteration or release cycle of all of the teams involved as they work to different cadences
Setup time in the room was important so that when people entered we were ready to go
Talking through the features that were delivered at the start felt like a waste of time as everyone could then talk through them with each team. This took time away from actual conversations so we decided not to keep it in the next one and bring our objectives wall into the room instead for people to refer to if wished.
Each team had someone viewing their demo at almost every ’round’ as we called them
Each team felt they got value out of it as they were able to have more in depth conversations and ask more questions about the features from other teams than they usually feel able to in the team specific reviews.
The teams who were concerned on repetition of reviews and their stall not having exciting enough features had ample interest, questions, and feedback for us to repeat this Science Review format again
Stakeholders and in-business users who would usually only attend the review sessions for specific features broadened their knowledge to the work from other teams
Introduction to the features at the start is unnecessary – this has now been replaced with bringing the feature board into the room
Worthwhile start to improving the cross-team knowledge sharing and communication. It did highlight how difficult it is for each team to keep up with and understand the work of 5 other teams whilst also maintaining their own work.
Requests were made from all to make the event more ‘jazzy and exciting to attend with an extension to more people included in this. Biscuits have been suggested
This review format allowed a different type of conversation to a solo team review which I believe was because there were less people at one time and so questions of more personal interest seemed appropriate. This is why I don’t believe it felt more repetitive
There are more interested people in the features than you immediately think of within the business
Extensions to try
Invite more people and advertise as an event around the business for whoever wants to attend.
Consideration on whether making it a competition for best stall would create a brighter atmosphere.