From User Stories to Storyboards to Tasks

For me, Sprint Planning is usually a day of doodling on white boards, sketching on paper, arguing and sticking post-it notes all around the room. The idea behind all this creative energy is simple:

1. The Product Owner is trying to revise the order of the items in the Product Backlog
2. The Team is helping the Product Owner by make suggestions about the order, based on their respective areas of experience. For example, the UX-guy might note that for end-users, certain products would go a long way to making the experience better. The developer-chick might note that a few bugs should be addressed sooner rather than later and that certain architecture needs to be built first before some of the other items can see the light of day
3. The Team then attempts to break up the items the Product Owner wants into User Stories, ie:

“As a [user role] I want to [do something] in order to
[have an outcome|get some value]“

From this point, most of the Teams I’ve coached want to break down the User Stories into tasks to get the job done. This is what I suggest to them instead in their Sprint Planning sessions.

1. Create Personas for User Stories

It’s not difficult to ask the Product Owner the types of people he thinks of off the top of his head that are typical of the types of users the functionality is aimed to serve.

• Create a list from the User Stories on post-it notes
• Work out their typical age category – Senior, Baby Boomer, Gen-X, Gen-Y and Gen-Z. Forrester data is easily discoverable by doing a google search. It’s categorised by generation and shows the likelihood of certain types of behaviour. Research by the BBC supports the hypothesis that the biggest factor in predicting online behaviour is people’s age.
• Note their geographical region – Metro, Rural or Regional. Data from the Australian Bureau of Statistics (ABS) notes that people’s use of digital channels is determined by their regionality. You might expect that city dwellers have the highest download usage, however remote Australians are one of the biggest use of 3G mobile broadband in the country. This is really only because ADSL/ADSL2+broadband isn’t available, cable is as rare as hen’s teeth, and satellite connections are patchy. Their best means of connecting — their 3G iPhone!

Personas start with something as simple as a list of post-it notes on the wall

Armed only with this data, you can get a real sense of where a Persona lives, their age, and what sorts of behaviour are they most likely to engage in — post photos on Flickr, create blog posts, join forums, or just spectate.

One more thing I like to add is the Persona’s motivations from a psychological perspective. That is, why do they do the things they do and what do they value. I just make it as simple as a reference to one or more things that Maslow’s Hierarchy of Needs, or French & Raven’s Power Theory, describes in relation to the Persona’s behaviour.

Adding a Persona's reasons for action -- their motivators -- helps to reinforce that what they're doing is an attempt to get a specific outcome as articulated in the User Story

2. Create a storyboard for the User Story

Taking onboard ISO: 13407‘s simple principles of creating an understanding of the context before you look at the requirements, I coach the Team to create a visual storyboard. This is as simple as getting a piece of butcher’s paper or even just a swag of post-it notes and setting out a logical sequence of events that depict the user (I try to reinforce that we use Personas) in the User Story.

Persona 'Claire' in the context of her use of a system

3. The functionality in its context of use

Obviously, the storyboard depicts certain system functions or products. The next step is to articulate what that functionality actually is likely to be.

Personas in the context of their environment, with benefits, outcomes, pain-points mitigated and functionality all listed against that context.

4. Describe the value of the functionality

What happens if you deliver the functionality in the context described? Does it mitigate a pain-point or a risk? Does it deliver some sort of ROI, outcome or benefit that the Product Owner described when he ordered the items in the Product Backlog?

Describing the value is important for traceability as well as for the user-experience. In creating this view of the Persona’s world, it establishes the rationale as a Team as to why ‘Gary’ (a Persona) needs his experience to unfold in a certain way.

5. Now its task time!

The ‘Epic’ on the window (yes, that’s what some people call it) is now the collective understanding of the finer detail in a User Story. Armed with this understanding amongst the Team as to what Gary wants, the Team can now have a much more informed way of deciding what tasks the Team need to do to make Gary’s experience a reality.

This is how I introduce UX to my Agile Team. It means, overall, that UX is integrated from the planning of each Sprint and right into the types of functionality that the developers will create. If you’d like to learn more about this way of working, Zen Ex Machina is running a workshop at Creative Camp in New Zealand. I hope to see you there!

M

Advertisement