DevSmart
Agile Stories
How to track Agile requirements with Windows SharePoint Services.
After three years of agile project management, I really enjoyed the flexibility and effectiveness of the agile approach but needed to find a better way of tracking requirements. The ideal approach would take into account the problems that are inherent with comprehensive upfront documentation, but still capture enough detail so that I didn't have to know everything about the product we were building.
User stories are a simple way to keep track of feature requirements without losing sight of the end goal: valuable software that works. "User Stories Applied: For Agile Software Development" by Mike Cohn (Addison-Wesley Professional, 2004) does an excellent job of teaching agilists how to create, estimate and plan projects based on simple user stories. As Cohn explains:
"A user story describes functionality that will be valuable to either a user or purchaser of a system or software. User stories are composed of three aspects:
- A written description of the story used for planning and as a reminder
- Conversations about the story that serve to flesh out details of the story
- Tests that convey and document details and that can be used to determine when a story is complete.
"Normally user stories are written on 3x5 cards, at least when a team is co-located. These cards are arranged on the wall based on the iteration they'll be built in, and moved around to show their status. A simple sentence is enough to help you keep track of an important feature you've promised to build without creating a requirements document that makes "War and Peace" look like a novella. On the back of the cards are the acceptance tests, which help drive out the details.
Sharing Stories
For distributed teams, user stories can easily be created and managed using a variety of technologies such as wikis, HTML tables or Windows SharePoint Services (WSS). WSS is an online collaboration product that's an integrated part of Windows Server 2003 and 2008, so you won't need to purchase a separate license for it if you're using these platforms. All you need is a SharePoint site configured with the security you require in the appropriate environment -- intranet or Internet -- and the authority to create custom lists.
Creating a custom list for tracking user stories is pretty straightforward. First, you create the list itself, then you create the views.
In my opinion, this is the bare minimum you need to get started with stories. You might also consider adding attributes for keeping track of subject matter experts, themes -- if you decide to group stories into themes-and sub-themes.
Once you've created a custom list, it's time to start with the views. I always keep the default "all items" view, because it makes it easy to edit the stories in a spreadsheet and sync them up later. The first view to add is an "iterations status" view, grouping stories by iteration, then by status. Then use this view as a base view every time you start a new iteration, filtering the stories so that only your current iteration appears in the view. You can even use WSS to total the story points in your iteration.
Virtual Wall
Once you have your list and views set up, using your Web-based story wall isn't really any different in practice from using stories printed on cards and taped to a real wall. Here's how it works:
-
At the beginning of the iteration, the whole development team estimates the complexity of each story you think might be in scope for the iteration. Update each story in real time as you discuss it. It's great if you can gather in person for this, but if you can't, just set up a conference call and make sure everyone has access to your WSS site.
- Start assigning the stories to your current iteration -- using your iteration field -- and watch the story points total for that iteration. When it gets close to your target velocity, stop adding stories. Your iteration is now scoped.
- Let the development team volunteer for stories. It usually only takes a few minutes for everyone to grab one or two stories to work on, based on their affinity for the theme of the stories. They volunteer for a story by simply putting their name in the assignment field.
- Use the WSS story list to track progress. Make sure the development team moves a story they have started to Work In Progress, and to Complete when they've finished testing.
- Continue this way until all the stories are complete or the iteration closes. Make sure to check your target velocity-planned story points per iteration -- against your actual velocity. Did you complete as much as you thought you could?
You can proceed this way through all of your iterations, using WSS and user stories to make it easy to keep track of requirements without creating a documentation burden that slows your team down and takes the fun out of agile software development.