Agile – When is the right time to go to users?

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 process”?

No project really starts out from scratch. Typically, in most public and private organisations, a budget is assigned after some work is done to persuade others that the project is a worth while endeavour to spend money on. Here, the scope is defined and approved and the project proceeds. If it’s a Scrum project, the Product Backlog needs to be established so that the first Sprint can begin.

Getting to users before the project begins

The best time to go to users in this scenario would be before the proejct even begins, during the development of the initial scope and business case. Some UX organisations specialise in this aspect of project development, calling it the Experience Vision.

Going to users to create the Product Backlog

Overall, however, the rules of Scrum dictate that writing the Product Backlog must be done just-in-time and with just enough detail. While many Scrum practitioners suggest that the Team should do no more than write a few words of a user story on an index card to represent each Product Backlog item. Scrum veterans like Mike Cohn, though, suggest a more pragmatic solution noting that overall the Product Backlog should be captured just-in-time and in just-enough detail for the Team to go from Product Backlog item to working, tested feature within a Sprint. For me, this means going to users at the beginning of the project when the Product Backlog is first being created.

I recently did some Scrum Coaching work for a large project transitioning from Waterfall to Scrum. Our first activity was to turn their existing 2 years of documentation into a Product Backlog. We orchestrated a 2 hour workshop with Morville’s UX honeycomb model as the core:

  1. In small groups of five, users were asked to categorise all of the functionality against one (or more) of the elements of the model
  2. Users then used a target to sort that functionality from highest value (in the centre) and functionality of lesser value in the circles away from the centre
  3. All of the users then came togetherto 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 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

At Zen Ex Machina, we also include the value and Lean statements in the BDD story:

  • 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

Of course, the Product Owner has the final say on the order of delivery, but this goes some way to ensuring the Team (who I make sure is present at this workshop) has a great understanding of a users’ perspective on the project’s outcomes. I encourage Teams to create Personas as descriptions of the roles they’ve seen at the workshop and include any known information or data on their motivations and behaviours. With the existing familiarity of the users’ market and demographics from the Product Owner (primacy/recency effect suggests that what he can say ‘off the top of his head’ is likely to be the most relevant aspects anyway) and the workshop experience had by the Team, Personas usually take the form of a few post-it notes on the product or task wall. Over time, however, I encourage my Teams to actively evolve their understanding of users and iterate the Personas into a more formal format on a single A4 page.

Articulating what users value during Sprint Planning

Unfortunately, I often come to projects further along downstream to find that no understanding of users has been elicited. Modern Agile’s approach has had its criticisms in this area before. Indeed, Scrum places no requirement of embedding an understanding of what users value into its process. Infact, the Product Owner alone dictates the order of delivery of Product Backlog items based on what they perceive as valueable to deliver. This may or may not include a user-value proposition. One suggestion is that this is the fault of a user-story approach where only a users’ outcome is required to be articulated and not what they value and why.

Chris Sterling of Volaro suggests an approach during the creation of user stories in Sprint Planning for a particular Sprint. He suggests creating value-driven user stories by asking the question, “who is interested in attaining the values that are being provided by this [product or epic]?”. I don’t know of any business owner or Product Owner who doesn’t know a fair bit about their users, so involving them is critical in such a process.

Going to users mid-Sprint

The Team should spend 10% of its time planning just enough detail at the beginning of each Sprint. During this time, I assess the need to go to users in the coming Sprint. I’ll typically initiate this conversation with the Team for the following reasons:

  • There’s not enough understanding of what users might need for the Team to create the Product (against the Definition of Done)
  • There’s a need to involve users to gain buy-in into what the Team is doing
  • There’s a need to set expectations about what users will get at the end of the Sprint

Assuming Sprint Planning occurs on Monday, there’s enough time (in my experience) for a UX practitioner to create a workshop outline, invite handy, close-by, friendly users and hold a workshop by Wednesday. Keeping the scope of the workshop lean and focussed is key — both for providing clarity around the understanding gap, getting what the Team needs to complete the specified product by the end of the Sprint, as well as (and this is so important) not wasting the time of users.

Conclusions

There are many times a Team should go to users. Overall, in an Agile project, the question is more ‘why’ than ‘when’. To me, that is a question about clarity of vision, direction and outcome of the Products the Team is creating. When there is ambiguity of understanding in the Team then an alternative perspective is required — and that’s where users play an important role. I often read debates about whether co-design is a good idea, and whether or not users can innovate, but the real reason I go to users is ultimately to seek an alternate perspective. Their outputs might not solve a problem, but it always provides me with a different way of looking at things that is enough to solve the impediment at hand. That’s why I go to users and that ultimately dictates when.

M

Advertisements