User stories can help keep your project manageable, focused on objectives, and adaptable to changing or newly identified needs. But what happens if the clients you’re delivering for are not themselves users? How do you write clear user stories when you have demands from experts and specialists with domain knowledge, while the actual end-users are nowhere to be seen?

What are user stories?

I gave a definition of user stories in my previous post on writing user stories and even covered some of their history. However, that was two years ago – itself pretty historic in blog years – and you may not want all the background. Perhaps a recap is in order:

A user story, simply put, is a concise way of representing a single requirement of a customer or user.

Traditionally a user story should fit on one side of an index card and not be too broad in scope. It could be as simple as:

The user should be able to search for a course by title.

Of course this story might be refined even further. There might, in fact, be several stories here. And instead of simply referring to the user, one could be more specific and refer to a specific type of user, or persona, or audience.

Traditionally, the back of the physical card is reserved for tests that developers check to ensure their code fulfils the story. These tests are called “acceptance criteria”. There’s considerable overlap between this approach and the approach I described in my post on behaviour-driven development a couple of weeks ago.

Why revisit user stories?

By keeping a log of user stories you can break down your eventual product – whether it’s a piece of software or a piece of writing – into components that each fulfil different user needs and can then be worked through and tested separately. I wanted to reflect on this technique again because, two years on, I have more experience and in different contexts, not only of working with user stories but also of seeing them being used by others.

I was also inspired by Sarah Richards’ talk on writing user stories at Agile Content Conf 2016 in February. Sarah Richards headed up Content Design at the Government Digital Service and is now a content strategist and digital consultant.

As noted in my post on pair-programming and pair-writing, a number of Agile techniques that began life in the area of programming and software engineering are now finding newer life in the world of writing and content. User stories are one of those techniques. It was interesting to hear Sarah talk about this from the content perspective.

What was the world like before user stories?

Sarah described the traditional process for working with content and for publishing as a “waterfall” approach.

Waterfall, as project methodology, is often considered as being opposite to Agile. Elements of the two can of course be combined. But the traditional process, as Sarah put it, is one in which a piece of content would move from person to person, through drafting and editing stages, without the people at the earlier stages really ever seeing it again until publication.

She described the process for content now as being more “jelly-like”, with overlapping stages and with objectives being revisited throughout the process. Agile project management works in this way, acknowledging and trying to actively accommodate the fact that requirements can change – either due to changing external circumstances or due to the fact that the project itself uncovers new problems or opportunities.

User stories can form the backbone of such an approach as they can provide building blocks (the vertebrae, if you like) by which objectives are defined and redefined as a project progresses.

Is it really that simple?

Although the concept sounds – and, fundamentally, is – simple, user stories can be difficult to write. Particularly if you don’t have access to end-users. Often, in the team I work in at least, user requirements come to us second-hand; we negotiate with subject-matter experts who themselves are trying to understand the users.

I can imagine this being the case in a lot of areas.

  • You could be an agency producing a website for a business which needs to reach its customers.
  • Your client, the business, is – or should be – an expert in what it does. It is almost certainly more knowledgeable about aspects of its market than you are. But it may not understand what its customers needs are when it comes to the web, or how to translate those needs to a form that makes sense on the web.
  • As an agency you have to be able to balance what the business is telling you with your own understanding. Their expertise needs to be tempered by your expertise of the particular medium you’re using, in this case the web.
  • But sometimes the business can make demands that seem to conflict with your own experience. That can be challenging; they are, after all, your client.

Sarah talked about the actual experience of writing user stories with such clients – with subject-matter experts – and sharing responsibility for determining project objectives and how they should be achieved.

So, what are the benefits?

The benefits of writing user stories are various and in some ways obvious; Sarah helpfully listed a few:

  • Assumptions are recorded and thereby made explicit. Things aren’t just made up as the project unfolds and people don’t have ideas “stuck in their heads”.
  • Reduced duplication. Rather than treating user needs as separate and creating objectives that may diverge from that, the stories cover both at once.
  • Facilitates sharing of skills and strengths. In this way, project stakeholders work together on definitions for the project and for project success.

But what are risks?

Subject-matter experts may have decades of experience and knowledge – that’s what helps make them experts!

Therefore, for them, there’s a risk that the content experience can feel quite demeaning, Sarah argued, because it implies that all their experience and knowledge can be distilled into a single line or a paragraph.

Subject-matter experts may also be reluctant recognise that, for their intended audience, not all their knowledge is useful, relevant or even interesting.

Nonetheless, experts may feel that they “carry the can”, that they take the responsibility if content is factually inaccurate or misleading.

Are there ways to mitigate these risks?

It’s important for subject-matter experts to recognise what content producers bring to the table. Otherwise, why not just have the experts write the content themselves? They can write, can’t they?

When interacting with subject-matter expects, Sarah argues that we – we project managers, we programmers, we producers of content! – should emphasise the need to discover the appropriate language, the appropriate mental models, and the appropriate thought processes for introducing specialist knowledge to the required audiences.

In other words, we should work with the subject-matter experts towards thinking about information architecture.

An outline of a user story session

Sarah described what she saw as a useful session outline for achieving this:

  1. Make clear up-front how you want to use the time. This should help focus any conversations and limit digressions. In theory.
  2. Define the outcome. This should make it clear that the point of the session is not just to have a conversation but to leave with something more tangible to work from.
  3. Ask the experts what they think people are looking for. Make this a list or add it to a spreadsheet. (I’ve tended to do the latter.)
  4. Bring user research to the table. You could in the session, or before it, turn this into a list or a spreadsheet of some kind.
  5. Compare the two. See how what the expert has said compares with the research and have a conversation about the meaning of this and the priorities of each.

You should aim to come away with a set of stories. Each story should eventually have the aforementioned acceptance criteria, which determine when the content can be deemed to have fulfilled the story. These kinds of details might be worked out in the session or they might be worked out afterwards by email, as long as the session has got to a point where both sides understand the purpose of the project and what project completion and success looks like.

My own experience

I’ve been including my own thoughts as I’ve described each of the points Sarah made in her talk. But I think it’s worth disclosing more fully my own experience of designing and delivering this kind of session.

I want to talk, in particular, about a failure.

I have run a user stories session before, with a colleague, using the kind of structure described above. It ended up being a disaster. The subject-matter experts kept talking amongst themselves when we were supposed to be focused as a single group. Some experts spoke across each other. And the session was derailed early on as one of the participants, who we had asked for information to help us prepare the session, stood up and started giving a presentation – it was useful information but it would have been far more helpful if we had received it beforehand!

As if that wasn’t bad enough, the project we thought we were planning for ended up being twice as large as the one for which we’d originally been briefed – we found out that there were two products to consider, not one! But nobody had thought to tell us or think through whether two separate products made sense for the various end-users, which included not only multiple audiences and interest groups but also the people that would need to maintain and update the products.

My colleague and I walked away at the end of the workshop without having even started on a set of structured stories.

The project continues even now but unfortunately lurches from phase to phase without much clear direction. And many of the questions that continue to come up are about trying to work out what would be best for the end-user. If only we’d been able to deliver that workshop as we’d wanted.

Lessons learned

It’s always difficult to know what one could have done differently in such a situation.

With this chastening experience in mind, there are at least a couple of things I’ll do the next time I suspect I’m going to encounter such a group:

  • Hold separate sessions with different experts first. Not ideal in terms of time but it does allow each expert to have their own voice and means a group session can be run afterwards to draw everything together and discuss or debate. Divide and conquer.
  • Email the templates you intend to use in advance. I perhaps should have thought to do this sooner. But it carries the risk that experts will start compiling the stories in advance and incorrectly, without a real understanding of what’s needed. So you should make it clear that this isn’t homework as such but the sheet should give an idea of what we hope to get out of the session. Sending an example sheet from another project might also work. Set expectations.

Sarah’s top tips

Having said all that, I should stress that I found Sarah’s talk hugely helpful. I wish I’d seen it before I ran that disastrous session. Even though her outline was one I was already roughly following, I think hearing the talk earlier might have given me more confidence in the structure of the session. In a room full of people you see as experts, it can be difficult to remember that you have expertise to share too.

I’ll end with Sarah’s top tips, which I’ll be bearing in mind in future:

  1. Try it. Ask forgiveness, not permission. Avoid that feeling of “learnt helplessness”.
  2. Practice. Role-play creating user stories in a safer environment. Have someone play an antagonistic expert and come up with dummy stories, using role cue cards if needed. Learn to avoid writing “I think”.
  3. Remember that everyone is human. Remember that subject experts have spent a long time becoming experts – and may feel hurt if their perceive their ideas as being dismissed.
  4. Design with data. If you have evidence to back up your claims, don’t be afraid to say “Research shows…” If you don’t have evidence, get some.

Coming soon

This post follows my post on pair-programming and pair-writing which was also inspired by a talk at the Agile Content Conf 2016 I attended in February. I think I may have one or two more of these posts in me. I have lots of notes from that day and I’m enjoying reflecting on the talks and relating each one to my own experience.