7

Are there documented alternatives to user stories within Agile that UX can use to handle 'bigger picture' thinking?

For example, there may be a web page that has 3 distinct 'chunks' of development. The developers need these broken into individual stories so they can go off and start building all the back end connections to make them work.

However, these 3 'chunks' have to be designed as one holistic page from a UX and UI standpoint.

We're struggling how to accommodate that in the context of JIRA--where we're expected to break down stories into daily-trackable tasks.

Adding UX tasks under each user story is one way to handle it, but that's essentially duplicating tasks.

For example "create wireframes" would be a task for each story. But there's only one wireframe: the wireframe for the page.

So we're trying to find a way to pull out the UX task as a separately trackable element that doesn't overlap/interfere with the stories dev is using.

One thought would be a 'ux story' (for lack of a better term) that might read as:

As [developer on our team], I need [to know what the UI will be] so I can [build the solution].

To me, that sounds rather silly, and is more of a hack than anything, but this would allow us to then build tasks for UX to handle and easily track within one story.

Has anyone found a better way to handle this (short of moving UX out of the sprints in the first place...)?

The 'design spike' has been one suggestion, though everything I read says those should be used sparingly. And we need a solution for each sprint so that UX can work on tasks that dev can then implement the next sprint.

Improve this question
2
  • Agile works when you find the right balance. You shouldn't follow it so rigidly that you are scared to make a story just for general UI design. But also you can't just try to shoehorn your existing working method into agile management or you won't see the benefit. You need to adapt your working practices to allow minimal required work to produce a feature and avoid speculative work for stories that may change or never happen.
    – JamesRyan
    Jul 21, 2015 at 13:05
  • 1
    I faced a similar issue and we did use JIRA. For a sprint or two we followed the hack you mentioned, after which there were no more UX stories and the process failed. Eagerly waiting for an answer.
    – sudarsanyes
    Jul 22, 2015 at 15:41

3 Answers 3

Reset to default
6

Great question. I'll try and break it down into a couple of components of how to provide the holistic view and task management (and reference Jira documentation when I can). From what you have described, a user story to handle the 'bigger picture' thinking is called an Epic. An epic is essentially a large user story that can be broken down into a number of smaller user stories (JIRA Reference for Definition of Epic). Using epics provides a great way to roll up the 'chunks' of user stories that the development team need to provide a holistic view of what the requirement is. As I'm not too sure how your JIRA environment is setup, the following links are to a user guide for working with epics in Jira and a Q&A link as to how someone did an implementation in their JIRA environment of linking Epics with User Stories:

Your example with regards to task management is an interesting one in which I'll provide an opposing view point (even though how you manage tasks can be different for each Project Manager, I'll explain how I'd manage it). From the 'create wireframe' example, that task would be perfectly suited to an epic (as like you said they would be creating a wireframe for the whole page). However, each of those user stories would have specific components that need to be designed / wireframed within that page. By managing tasks at the user story level it can help ensure that the UX Designer has covered off all of the requirements for that epic. Another advantage of managing UX tasks at a user story level is that it can allow the development team to start developing the components for the user story once the UX tasks are finished rather than waiting for the epic to be completed (as I'm assuming you have your UX one sprint ahead of your development team).

In summary, to provide a holistic view of a few relevant user stories I'd start using epics but I would continue to manage UX tasks at a user story level.

Improve this answer
1
  • Scenario is another name for it. But in Agile it is called Epic.
    – FrankL
    Jul 22, 2015 at 5:28
3

The answer is a spike story

I heard people say there is no room for UX Design in Agile. But there is if you make the most out of it. You can do a spike story before pulling up the actual userstories from the backlog. A spike is a story or task aimed at answering a question or gathering information, rather than at producing shippable product. Sometimes a user story is generated that cannot be estimated until the development team does some actual work to resolve UX design problem. The solution is to create a “spike,” which is a story whose purpose is to provide the answer or solution. Like any other story or task, the spike is then given an estimate and included in the sprint backlog.

Please read :

http://agiledictionary.com/209/spike/

http://agileatlas.org/articles/item/spikes-in-scrum-the-exception-not-the-rule

During this spike you may need to come up with the available options (Wire frames) and run it through the customers or stake holders for the feedback (UX Reaserch).

Improve this answer
3
  • Spikes, to me, seem very much like a "oops, we forgot to accommodate UX in the first place". The biggest concern is when you see things like 'exception-not-the-rule' when referring to spikes. UX can't be the exception if the goal is to have a good user experience in the end.
    – DA01
    Jul 22, 2015 at 5:54
  • Yes, UX can't be the exception. Let's put it in this way "Finding something unknown".
    – Sachux
    Jul 22, 2015 at 6:20
  • that's the challenge with using spikes as a solution, though. It seems that most people agree that design spikes aren't supposed to be a regular part of the process...just a rare exception when needed.
    – DA01
    Jul 22, 2015 at 15:57
0

There are a lot of best practices out there. For my work the use case 2.0 model from Ivar Jacobsen works good. In general think about established process management models like use cases, think about agile stuff like user stories/epics/..., think about combining them for your business.

Use Case 2.0 Whitepaper

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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