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.
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:
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:
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 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.
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:
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.
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:
The value and order of features was then explicitly associated with User Stories in Behaviour Driven Design (BDD) format:
We also included statements on value and metrics in the BDD story, so that we could embed these metrics into OKRs:
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.
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 tesint has passed, Scrum teams:
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:
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.
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.
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.
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.
How do you write great User Stories?
How do you create an Increment of work in Scrum? What has it got to do with the Product Goal and Definition of Done?
Should you have business as Product Owners? Is the Release Train Engineer a Delivery Manager? Where do Project Managers go? Aren’t Epic Owners the executive? Everyone gets these things wrong. Find out how to avoid SAFe’s implementation traps.
Are you still asking the ‘three questions’. It’s time you learned some better patterns to inspect your progress toward the team’s Sprint Goal.
When things get stale, ROTI is a simple pattern for team feedback that places the ownus of actions for improvement back on them.
What does a Scrum Master do all day? Run events and facilitate meetings? The Scrum Master role has evolved greatly over the last 20 years and now encompasses leadership, coaching, and growing agility through Scrum.
Copyright © Zen Ex Machina® and ™ (2021). All rights reserved. ABN 93 153 194 220