2

My manager has asked me to create 1 or more UX stories for a project I'm about to begin. By a UX story, I'm not referring to the USER story (i.e. as an accountant I want to write checks so I can pay invoices).

I'm also not referring to UX tasks (e.g. research, wireframes, usability, visual design, etc).

I've heard of "non-stories" (to capture things like development research, or technical debt), upon which other stories actually depend and I'm wondering if UX stories fit into this category?

Do any of you document UX stories as part of your agile process? And if so, can you provide and example and explain the components?

  • Are you sure your manager didn't mean 'user story'? I'm not sure what the definition of a 'UX Story' is. I can't say I've heard that term used (not to say that it isn't a term being used out there...) Perhaps it's the 'how' companion to the user story? – DA01 Jan 27 '14 at 18:09
  • Are you perhaps instead thinking of a user Scenario? For example sally the 45 year old mother of two, has trouble navigating our system, she clicks on the menu and is overwhelmed by the number of options. Of course sally isn't a real person, she's the representative of a demographic. – VoronoiPotato Jan 27 '14 at 18:21
6

I've seen a lot of different exceptions made like this in agile - called spikes, buckets, non-stories, etc. This is doable - basically it's just an allotment of time. The only place I've seen it get ugly is when you assign an huge number of story points to it to account for the time you're taking to do many tasks, then you have a substantial portion of the sprint going from in-progress to done all at once - really defeats the point of a burndown. I think if you want to do it this way, don't try to track it as story points.

That behind me, I've also seen UX and UI integrated beautifully into agile user stories. To do it, it is necessary to break the design process into it's smaller parts. I'll try an example of a login process below. It might not be perfect because I'm doing it quickly about a hypothetical interface, so try to take the idea, not the details.

  • I would like a low-fidelity workflow of the login process so that I understand the different ways users will interact with the interface. (tasks might include a rapid prototyping session, hallway testing, etc).

  • I would like a standard added to the style guide for text inputs so that developers know how to format those elements in the login page.

  • I would like a standard added to the style guide for button inputs so that developers know how to format those elements in the login page.

  • I would like a standard added to the style guide for error messages...

  • I would like copy determined for login messaging.

  • I would like to run a usability test of a high-fidelity prototype.

And so on. These are pretty granular, I know, but my experience has been that this really pays off. It helps the rest of the team and the stakeholders see what you're putting into this application and it means a lot when you're demonstrating the value that your team has delivered in the sprint - that kind of team-integration is fairly important to Agile.

Edit: I forgot to mention, breaking it down like this also helps you pick the pieces you need to deliver for the team to move forward. This avoids that situation where you're asked to do absurd amounts of work in a short period of time - and that happens a lot. I can't count the number of times I saw developers say "well, we're stuck because the UI guys isn't done yet". They're not being jerks. They're asking you to turn out a full UI and they're waiting for everything before they start on anything - they just don't understand design enough to understand what they're doing. This approach helps you work on the same terms as the rest of the team.

  • but are those really user stories, then? They don't seem to be coming from the perspective of a user of the product. – DA01 Jul 2 '15 at 22:32
  • @DA01 the user subject in a user story doesn't have to dogmatically be a end-user - just whoever the piece of work if being created for – Fractional Jul 3 '15 at 13:32
1

A root idea of Agile is to only do things that add user value. So pretty much all activities should be attached to a User Story. There can be exceptions but try hard real hard not to use them. As an example even internal performance improvements are relevant to a story: Add acceptance criteria with response times on relevant user stories and mark as incomplete. The relevant tasks are then attached to tangible outcome.

If you start adding stand alone activities then focus on creating user value (the stories delivered) will slowly fade, and the benefits of Agile will be lost.

Note that one can use an "Epic" story to gather early research tasks or any other work that covers a wide scope. Be creative (but concrete) in associating the "UX Story" with one or more user stories.

Here is an example from high level UX (goal driven) to definitive (UI mockups) UX

mockup

download bmml source – Wireframes created with Balsamiq Mockups

  • I'd love to hear more examples about how to attach UX stories to more than one user story in a sprint. That's our current challenge. The thinking is that UX often has to be thought about at a higher, big-picture level and the user stories tend to be at a lower level. – DA01 Jul 2 '15 at 22:33
  • @DA01 good idea. I've added a diagram with partial example to make less abstract. Do note that if a particular team is using "Story" to actually mean "Task" that is an anti-pattern, because a task has no explicit user value. – Jason A. Jul 3 '15 at 13:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.