Given how long I’ve been thinking about Agile + User Experience, I can’t believe it’s taken me so long to start doing writing user stories that are centred on the personas we’ve created for the project. Nonetheless, it’s something I’ve started doing recently and I’ve found it to be really successful. I’m not the only one – Will Sansbury has written about it before and Joe Sokohl spoke about it recently at the Agile 2010 conference.
It’s as simple as it sounds – rather than writing user stories that nominate members of your project team, instead write them nominating the persona they are designed to most benefit.
For example, on the Project Verity backlog I’m working on with the team at Mark Boulton Design we have the occasional ‘as the developer, I want to…’ but the vast majority of our stories lead with ‘as Verity, I want to’, or occasionally ‘as Verity’s boss…’
This is, in theory, a teeny tiny change, but in practice I find it has two big effects.
Firstly, it keeps your personas alive and actively in use – this has always been a big challenge for UX people in agile and non-agile teams alike – here is one big opportunity where agile teams actually seem to have the edge.
Use your personas in your user stories and your personas can’t be left on a shelf to gather dust, instead they effectively become active members of your project team. If the stories don’t make sense with the personas, then either your story or the persona is at fault – the team needs to sort out which is at fault and make the appropriate adjustments. Which leads me to…
Secondly – it’s much harder to write a rubbish user story when it’s grounded in a persona. Let’s face it, there are plenty of user stories in most of our backlogs that are really management feature requests disguised as a user story. Transform your backlog so that the user stories that are supposedly there to help the users are given to a persona and suddenly it becomes much easier to interrogate feature requests against real users.
I can’t tell you how many user stories I’ve ended up throwing out because when I try to write the ‘so that I can…’ part of the user story it becomes impossible to make a compelling case because I have to make it gel with the agreed persona attributes.
I keep thinking – because I haven’t heard of people using this approach very much – that there must be some fatal flaw I’ve not thought of or come across yet… if so, perhaps you know what it is?
Making Agile & UX work together can certainly be tough, but this strikes me as one of those opportunities that Agile offers UXers to actually practice our craft all the more rigorously and visibly in our teams. I think I’ll be doing a lot more of it in the future.
Interesting and promising idea. I really like how this method keeps the persona in use and top-of-mind for the entire team.
The only possible barriers I can think of are (1) not all user experiences professionals use personas (for various reasons) and (2) at many companies the product managers (who may not see the value personas) write the user stories.
Nice one, Leisa! Can you show us some examples when you’re finished?
Now I just need to get time to produce personas before people start writing user stories! :)
A great read Leisa. At Lithe we use this approach of personas being the basis of user stories and we have found the result to be as you say: the personas remain alive and useful throughout the project and it really focuses the writing of the user stories. We also find this approach a fantastic one with clients: the link between the personas and the user stories triggers them to articulate a lot more of their knowledge about their users that sometimes remains hidden and helps to keep feature discussion grounded in user needs rather than wish lists and management whims/desires.
Hi Leisa. Great post – I’d also be keen to see an example or two if you can share.
Depending on your project, this next idea may add too much overhead, but I really like the way it ties everything together. Build up some task-analysis-grids around your persona and scenarios (see Zakiwarfel’s post – http://bit.ly/3pYSdc – for more details), but instead of having the bottom section dedicated to ‘functionality’, substitute it for ‘user stories’. It not only creates a really strong visual link from persona down to scenario down to user story, but my theory is that it should also help avoid a disjointed end user experience resulting from decisions being made in isolation from their context.
Anyway, looking forward to reading more. Keep up the great work.
Cheer. Marcus
I’m just wondering… You often write about your experiences with Agile, but in my experiences working with you, you worked in a permanent iteration zero – which is really waterfall. Have you worked in an ongoing agile process? And, if so, can you point me to some of your findings?
I ask, because I find agile to be destructive to design. I just came back from agile 2010 where I hoped to learn how others were tackling design in agile, and all I learned was that others practicing agile were hitting the same problems:
– Agile focuses on working code and business value. Sprints force developers to cut up big ideas into small achievable stories. This often results in working code with no polish or whiz-bang (the stuff that makes up the UX). Next sprint, polish is weighed against the next biggest feature, and the next biggest feature usually wins because product owners are not usually designers, and because designers are usually outnumbered by business and developers.
– Because sprints are 2-3 weeks, there’s not enough time to research, design, prototype and test in one sprint. Often it requires several sprints which can be looked at as a waterfall approach. The only companies that were able to make this work, were companies with large enough wallets to have their own research teams that were one sprint ahead of the design team.
– Sprint two (and all others for that matter), is where developers start to build your work. But usually there are lots of questions. In my practice, 25% of my velocity is lost just answering questions from the previous sprint.
I’m interested in your response. What have you done to protect the user experience in a feature rich product with smaller budgets?
Jeff, sure, I’ve worked on a quite a few agile projects that have progressed beyond iteration zero – with varying degrees of success.
On projects where the product owners are designers OR really care about design and what designers have to say, Agile has a chance of working in a UX friendly way.
If it is a combative environment for designers, as the one you describe where the designer is ‘outnumbered’ then, I agree, you’re pretty much screwed – you can just try to make the best of a pretty average situation.
The projects we worked on together were exactly that – a combat zone between developers & designers.
Agile is not a silver bullet – the larger the team, the more code/feature (as opposed to design/ux) driven the team, the more difficult it’s going to be to design well. I’ve certainly worked in environments where anytime I wanted to have a design/ux ‘spike’ to do some strategic work, I was told that I wasn’t being agile (which is, of course, a total crock).
These days, given the choice, I’ll only work on small Agile teams with smart people where design/UX is really given priority over coding up as many features as possible as quickly as possible.
But I often have to design, strategise, test, research and answer questions all at once in 2 week iterations in amongst all of the standing up, reviewing and planning that agile requires. It’s tough, and you have to cut corners but – with a good, smart, supportive team – in my experience it’s achievable.
Jeff- the other thing I was wondering – whether the only people who have time/budget to go to Agile 2010 and similar are working in exactly those big, bulky, developer/feature centric project teams/companies where Agile operates at it’s worst for designers….?
Could be. I didn’t get that sense though. TheLadders.com was one company that shared many of my pains. They’re pretty small, I think like 320 people total across US and London.
I think 320 is big – by my standards of environments most likely to succeed with Agile.
[…] e user stories from progettareperlepersone by stefano Vi segnaliamo un articolo, Persona driven user stories for Agile UX, nel quale Leisa Reichelt descrive la sua esperienza con personaggi e user […]
Leisa, this was really inspiring :)
I have as you (and Jeff) often experienced the same pains figuring out how to at least phrase the ‘as a user…’ to make it seem that this particular feature was actually derived from intense user studies. I have an opportunity to create personas for my next project, and I hope this will give the personas – and the user stories – the role I always believed they should have: Carry data and ideas in a selfexplanatory and meaningful way through the project.
I am happy to see that you are back on track Disambiguity on and hope you still get the time to enjoy your baby :)
[…] Persona driven user stories for Agile UX (disambiguity.com) […]