Mat Walker

Now I’m a few posts in I think its probably a good time to start talking a bit about the agile ux process we’ve been developing at the BFI and the lessons we’ve learn’t along the way. So lets start at the top with Sprint 0!

Like it or not Sprint 0 is a well developed practice within Scrum. For developers its the time when they get to do all of the setup and prep work they need to do before they can start coding features and stories. In the bad old days of Scrum it was also the time when the UX part of the project got dumped. As a freelancer I’ve worked on a number of agile projects and been asked to produce the IA for a new website which has been shoe horned into Sprint 0 along with all the other UX deliverables. This approach makes life very difficult for the IA as they often have to work with an undefined set of requirements and quite often its also the last time you see these wireframes before they get pulled apart and turned into user stories for the backlog, changing beyond all recognition as the project develops.

We decided against taking this approach for the BFI redevelopment project and opted to treat UX the same as dev in Sprint 0. Getting all the initial user research done ahead of starting the project proper  would help the IA and design process when we move into the development phase with the IA getting developed in conjunction with the development effort. In case you’re interested our Sprint 0 lasted a couple of months.

Here is a list of the work we did, roughly in order. YMMV:

Personas – As with any other user centred design project the first place to start is with the initial user research and getting personas developed. If you only ever take one thing away from this post then make it this. In an Agile UX environment personas are worth their weight in gold! I’m sure you’ve worked on projects in the past where personas have been tacked onto the side of a project as an after thought and never used again. However in an Agile world where the backlog and user stories are constantly being validated and reassessed having personas to sense check these decisions against is invaluable.

The personas were designed in the normal way and amongst other things we’ve used them in this project for:

• User Journeys (more on this in a bit)
• User Stories (the bits that make up the backlog)
• Recruiting participants for user testing
• Team building (I’ll tell you about this in a further post!)
• Backlog Prioritisation (more about this here)

Site Map – Before we could start writing user stories and looking at the first Sprint we had to develop a site map. All of the UX deliverables we have produced are flexible and are based on our knowledge at the time, they may (and often do) change over time and the site map is no exception. To date its been through 9 revisions as our knowledge has increased and is likely to change again before launch. To develop the site map we conducted a content audit of the site (to give you an idea of scale we stopped at 9 levels down and logged nearly 1000 pages!) We then took a digital red pen to the audit cutting out huge swathes of redundant content only leaving the good stuff behind. When we had reduced the audit down to something more manageable we then added sections for some additional site content for the site that we were aware of. This was then passed through an open card sort with prospective users of the site who were recruited against the personas and formed the basis of the site map.

You’ll see from the site map we produced that we went for a slightly different, non hierarchical approach to the map for a couple of reasons. The first was that we didn’t want to give the impression to the stakeholders in the organisation that one section was more important that another and the second was that because the content of the map is always changing it is easier to not bog ourselves down with details around where content should fit in the hierarchy at this stage.

User Journeys – The final stage of our UX sprint 0 was to develop typical user journeys for the new site based on the behaviours of the characters in our personas. We developed about 12 journeys and a typical journey looked like this:

“1. Book tickets to a screening

Nick has heard that Tron 3D has been released and loved the original, so has convinced his friends to go see it with him next Friday. He Googles to see if it’s on at the IMAX. One of his friend is a student and want a cheap ticket.

Main journey:

Google > BFI, What’s on > select 5 tickets for the best seats on the xx^th of Sept early evening (inc student ticket) > Pay > Get confirmation >

Further routes:

> Watch trailer/read (Sight & Sound) review/director interview (BFI live)

> If you like this, you may also like…

> subscribe to newsletter (upcoming films of same type?)

> become a member (emphasis on cheap tickets / how to save on tickets next time?)

> Explore the collection ‘Science in films as threat or danger’  (Special Collection) > Watch videos”

As with the site map we published these stories with a huge “This will change over time!” caveat but they were useful as a way of guiding the stakeholders and Product Owner when we started looking at the development roadmap. In order to develop the roadmap we prioritised the stories according to business goals, ease of development, and our knowledge of the organisation (the BFI has been through a massive restructuring during the lifetime of the project). The prioritised list of user journeys was then used to guide what went into the first sprint.

If you’re interested in reading more about using user journeys Jeff Patton has blogged about this.

So there you go. That was our Sprint 0. For seasoned UX professionals there’s nothing exactly earth shattering in there but from an Agile perspective it was definitely the right way to go about for this project and getting this stage of the project right helped the rest of the project no end. You’ll also notice that not one wireframe was produced during this phase!

In a future post I’ll write about how we work with Agile and UX in our sprints….watch this space!

Today I spent a bit of time putting together some UX flavoured templates for our user stories which I thought I’d share with you. As you can see from the screen grab below the templates themselves are pretty standard but I’ve added some UCD goodness to keep the team focused on who we are building this for but at the same time keeping it true to Scrum.

Because I produced the templates for my own use I’ve not included any guides or a key with the templates. Below is a brief overview of the various elements:

• ID – User story unique identifier
• Wireframe No. – Area or wireframe page which user story refers to
• Priority – Business priority (just in case it falls off the wall!)
• Est. Size – Estimated size (durr!)
• PIctures on LH side – Pictures of personas. Replace the placeholders with the pictures you use for your personas and cross out the pictures which story is not relevant to. This will help the product owner when prioritising the backlog and also act as a reminder to the rest of the team.
• User story – Nick would like to _____ in order to ______ etc etc
• Boxes in bottom LH side – These statements refer to the Kano method which we use as part of user testing as a way of validating the various features. The reason why we include them on the story card is to help the product owner when prioritising the backlog. More on this here.
• Boxes on bottom RH side – These are our acceptance criteria for user stories. All of the stories must have been through a round of user testing, passed unit testing and also been signed off as acceptable by the Product Owner.

Feel free to download the original Omnigraffle file or the PDF and amend it to suit your needs. They’re double sided so if you have access to a duplex printer you can print two double sided templates per page of A4. If you have any feedback or suggestions please do let me know!