A UX colleague and friend of mine recently asked me, “when do you typically suggest the ‘right time’ to go to users is in an agile way of working”? Agile practices are very different to traditional linear, Waterfall methods. Rather than only engage people at the beginning and then at the very end, agile teams have many opportunities to continually engage with users each and every Sprint.
Engaging users with a Lean Business Canvas
Business cases in agile organisations typically consist of a Business Canvas of some kind. It defines the problem, who the users are who will receive the benefit of some solution to their current needs.
This requires agile teams to:
- Do user research – what is the problem we’re trying to solve and for who? Personas will often emerge out of this activity and their needs documented on the canvas.
- Consider high-level solutions – technical, business rules, and processes involved.
These activities are all part of Backlog Refinement. An agile team will typically spend around 10% of a Sprint looking at work in future Sprints, and doings things like:
- User research – improving our understanding of users’ needs.
- Technical research – what does good practice look like in the industry?
- Analysing the results of research and incoming data on how users are using features that have been delivered in previous Sprints.
- Engaging with users and stakeholders in various workshops.
- Doing high-level analysis and design.
When large “project”-sized work is coming to the team, you might need to spend more than 10% learning and researching. Ultimately, it’s up to the Product Owner to consider what is of value and to negotiate with the rest of the Scrum Team as to how much time needs to be put aside, noting that the boundaries for self-management still require the team to produce an Increment of value by the end of the Sprint.
Story mapping helps engage and visualise users' needs
Story mapping is one of my favourite workshop activities to do with teams, their stakeholders, and (if possible) with end-users. Where a product breakdown structure creates a tree-like view of the breakdown of large solutions into smaller and smaller items, story mapping looks at the user journey and identifies the potential features that fit into that user journey.
Potential solutions go into the Business Canvas and the features into the Product Backlog.
Co-designing with users with Design Studio
Design Studio workshop methodology is another technique I use. It combines divergent and convergent thinking to allow agile teams to explore a wide set of ideas. It’s great for creating a shared vision to move forward within a short amount of time. In one condensed session, it incorporates:
- Brainstorming – ideation activities to generate ideas.
- Critique – guiding attendees through design-critique discussions
- Prioritisation – to build consensus on possible design directions or valuable features.
The outcome is the same as story mapping – valued features that are essentially hypotheses. That is, we think that these features will solve the defined users’ problem and deliver them value.
Writing "Stories" together
I recently did some Scrum Coaching work for a large agile transformation. We orchestrated a 2 hour workshop with Peter Morville’s UX honeycomb model as the core:
- In small groups of five, users were asked to categorise all of the functionality against one (or more) of the elements of the model.
- Users then used a target diagram to sort that functionality from highest value (in the centre) and functionality of lesser value in the circles away from the centre.
- All of the users then came together to create consensus of the order of delivery of all of the features.
The value and order of features was then explicitly associated with User Stories in Behaviour Driven Design (BDD) format:
- GIVEN that a customer buys a blue garment
- AND I have two blue garments in stock
- AND three black garments in stock.
- WHEN he returns the garment for a replacement in black,
- THEN I should have three blue garments in stock
- AND two black garments in stock
We also included statements on value and metrics in the BDD story, so that we could embed these metrics into OKRs:
- GIVEN that a Customer buys a blue garment
- AND I value good, fast customer service
- AND I have two blue garments in stock
- AND three black garments in stock.
- WHEN he returns the garment for a replacement in black,
- THEN I should have three blue garments in stock
- AND two black garments in stock
- AND the current process of replacement will be reduced by 10 minutes
User testing
What is it and how does it usually work in Waterfall?
In Waterfall, the whole product development effort typically goes through “user acceptance testing”. Often, usability testing and some form of user testing is also conducted. This type of testing helps to ensure that the product is potentially releasable and provides stakeholders with a gateway approval point to both confirm for themselves that it’s what they want, and to sign-off on the hand-over of product ownership to the business.
User Acceptance Testing (UAT) is the final point at which, all throughout the project, the product can be confirmed to be “potentially releasable”. The lead time as a result is typically very long – months or even years.
How does user testing work in Agile?
The work the Scrum Team does must meet a specific quality criteria – the Definition of Done. The Definition of Done is a formal description of the quality measures required for the product. Often, this includes that work has been tested with users and no defects have been found.
Sometimes, additional work must be carried out to ensure that features can be potentially released. Elements of a high risk call centre, for example, may have to be tested by the call centre staff, with dry runs through their scripts, for those features to be considered for release.
Unlike Waterfall, where testing continues until the activity has been deemed “complete” or until business signs-off that testing has passed, Scrum teams:
- Must complete all of the work taken into the Sprint by the end of the Sprint.
- Ensure that it meets the Definition of Done
- Ensure it meets any acceptance criteria.
It’s up to the whole team to work out a plan on how they’ll achieve this outcome. For some teams, learning how to do this takes many Sprints. Most teams, though, will increment their way through a piece at a time, including:
- “Slice” the feature into smaller pieces so that all the testing needed can fit into the Sprint.
- Do “guerrilla usability testing” in the field.
- Test with a smaller group rather than test with everyone. There’s good research to suggest that by the time you’ve tested with 9 users you will have found the majority of defects (Nielsen, 2012).
- Design, build and test only a few parts or steps of a process per Sprint.
High risk elements often have more stringent acceptance criteria, increasing its size and thereby reducing the total number of such items that can be done in a single Sprint. It might, therefore, take several Sprints to deliver all of these.
Once each of the pieces of each feature is potentially releasable, the Product Owner will then decide when it’s time to release the whole feature. It might take many Sprints before the whole feature or a set of features is released.
Eliciting feedback in Sprint Review
Traditional Waterfall projects take months before stakeholders will see a potentially releasable Increment. In Scrum, stakeholders are invited by the Product Owner to the Sprint Review where stakeholders will be shown that features are potentially releasable. This happens every Sprint – typically every two weeks.
The type of scripts that stakeholders use in the UAT stage are instead created by agile teams, used as acceptance criteria, and then used to demonstrate features are functional with no defects at Sprint Review. Feedback is elicited at this time and discussed, along with the state of the Product Backlog, the budget, any changes to forecasts of when features will be delivered. Any feedback, including new features, are recorded in the Product Backlog to be potentially delivered in future Sprints.
Conclusions
There are many times agile teams could go to users. The better question is ‘why’ not ‘when’.
To me, this is a question about clarity of vision, direction, and outcome of the product the Product Owner is creating with their Scrum Team. When there is ambiguity of understanding in the team then an alternative perspective is required – and that’s where users play an important role. Their input might not solve a problem, but it always provides me with a different way of looking at things.
M
Download ZXM Business Canvas
ZXM’s EBM Business Canvas aligns strategic planning activities with investment initiatives and Evidence Based Management (EBM). It fits in perfectly with Toyota Kata planning and learning cycles.
