Using a Wiki for Agile User Stories

User Story: 2-3 line base definition of a feature with test(s) to tell the developer when the feature is complete. Each User Story has a unique number and is assigned to a sprint or iteration after the business-development team negotiation for a Kick-Off.

The Agile Books will tell you to put the User Stories on 4" x 6" cards with the tests on the back. This allows the developers and business team member to easily identify dependencies, move cards around for planning, carry the cards when a developer talks to an end user or stake holder and to throw them out when the sprint is complete.

• This will work fine a small project for an organization that has some experience with Agile Development.
• It will fail with a large project and an organization that is moving to Agile methods.

Then came wikis. You've used them (Wikipedia is the most famous example). The idea is to allow any one with access to edit or comment on anything in the wiki. And we had to figure out a way to put User Stories (written by the B.A. or Information Architect, not the Business Team Member assigned to the project) up on the wiki. And allow as much flexibility as using 4" x 6" index cards.

We used Confluence because it dovetailed so nicely with the issues tracker/project management application Jira.to As a consultant, I've dealt with more of the latter than the former.  As per usual- someone said, 'Scot, take care of this.'

I don't know about other wikis, but I have to believe they're pretty much the same. Confluence allows administrators to create templates. Once created, wiki users can then simply bring up a new page and apply the template. Here;s what I included after looking at a brilliant Information Architect's (Alice Toth at Pathfinder Development) first draft, here's what I included in the template:

• Project Abbreviation/User Story Number- if it's an issue, we added the Jira Link to this section.
  
• User Story: (who does what and what happens as a result in 2-4 sentences
• Workflow- as required, quickly documents where in an end user's work flow this occurs and simple error handling.
• Business Rules- as required-rules the business imposes or needs for the User Story to work properly
• Wireframe(s)- low to medium resolution wireframe as required
  
• Test: Two column table- first column labeled Action, second column labeled Expect Result with 10 or so rows (can be added to or deleted from the table as required.
  

As for the flexibility for moving cards around? That's what the Sprint Page is for!




Next up: The Problems of Agile Adoption

Powered by ScribeFire.