I get asked about my favorite tips and tricks for writing stories in an agile backlog.  One of my tips is to make it EASY for the engineers – give them “one stop shopping”.  Engineers aren’t lazy, but they don’t like having to hunt about for the documents and other artifacts they need to be able to build the software that delivers against a user story in their sprint backlog.  This means that when the story is getting fleshed out (elaboration), we want all the supporting artifacts to be attached or linked.

Do you have a process flow that the story fits into?  Link or attach the process flow.  Have a mockup (e.g., Balsamiq mock-up)?  Attach it.  Is there an important pre- or post-condition?  Spell them out in the story.  You want to have enough associated right there in the product backlog item that the developers– and by developers I mean engineering, quality assurance, documentation, and anyone else on the Scrum team—to be able to understand what is wanted and to launch off to create the deliverable increment.  Of course, there is the standard agile caveat that you provide just enough documentation to build, with the understanding that a “story is a promise of a conversation” (credits to Alistair Cockburn).

If you have a 100 page UX document with all the low fidelity mockups, organization UI standards, high-fidelity mockups, color palettes, and so on, it is useful to link that to stories BUT it can make it hard to reference the particular page or figure that relates to the story we’re working on.  If the document is changing all the time, it gets even harder.  Consider the pros and cons of having a large doc, or a set of smaller docs – there are good arguments both ways.

I’ve worked with various organizations, using a variety of backlog management tools, from “on-the-wall” with 3×5 cards to Microsoft’s Team Foundation Server (TFS), JIRA Agile, ScrumWorks, and others.  No matter which tool it is, you can put in the same information – though some tools are better than others at linking the story to other useful bits. I like to have a simple title for the story that carries a bit of info about the epic it belongs to (nearly all stories fit into some sort of epic, in my experience). So, a story that belongs to the “New Tools” epic might be named “New Tools – Widgetizer”.  Even if your tool shows the epic, it’s nice to have it in the title when you do things like export to a spreadsheet or do a printout.    You will include the user story bit – As a… I want to… So I can… – and the acceptance criteria in the “body”.   Some folks like having the story part show in the “Summary” field so it is in the backlog view in JIRA Agile, for example, but I find that adds a lot of words that people have to parse and skip to find stories.  The short title makes it easier to move stories about, locate it when grooming, and such.

You may end up duplicating links or attaching things multiple times, but that’s OK.  The engineers appreciate it when everything is at their fingertips.