Keeping Track Of Stories

How do you keep track of your UserStories?

Write 'em on cards, [Customer] keep[s] 'em in a lunchbox. How long are your iterations? How quickly do your users' priorities change?

Iterations are two weeks. Priorities change every iteration. Why do you ask?

We found that with priorities changing every couple of weeks and stories being clarified and/or rewritten, it was just too hard to keep track of everything manually. Also, we have a somewhat geographically dispersed team, so it helps to keep everything electronically to develop status e-mails.

If you're distributed, all bets are off. The phrase "rewritten" makes me think there are more words in your stories than might be ideal on a one-room project. No on-site customer => more writing.

What you say is almost certainly true. There's another force in our project that encourages more writing than may be typical: Each story is implemented with a fixed cost. This encourages small, well defined stories that are clearly communicated and written down.

We are a consulting company contracted to develop a web application for our clients. The system has been live for about the last 4 months and we are rolling in new features at the rate of about one or two user stories per week.

We have a simple access database to track our stories, bugs and maintenance tasks. We track each of those separately because of the way the contract is written. For stories, we track the story itself, the date it was created, cost and time estimates to complete and its priority (thinking about it, we should probably also track who initially requested the story, but we haven't really needed that feature yet). We typically implement the stories in priority order.

When the users want to add a new story, we'll hash out the story initially through e-mail, phone conversations or face to face meetings as necessary. Then, we'll add just the story to the database. At some point later, the users will want to have an estimate to complete the story and we'll provide one. We only estimate stories when asked.

Every week, we'll re-estimate stories as required and send out an email containing a list of the prioritized and unprioritized stories to our users. If we're stuck on a story because of some question we have or some other issue, this email provides a great way to raise the visibility of the issue to our users. They respond with new priorities and clarifications to stories and we update the database.

Has anyone considered using Wiki as a place to hold User Stories and engineering task lists?

We use a wiki (OpenWiki) to keep track of our projects and user stories. The only downside to it is that the level of management reporting that we have to do, does not lend itself well to a wiki. As in, I'd much rather have a more rigid system and database to store the information in, so that I could quickly and easily generate reports of "where we are" and "how much time is left" so that I can please the management types.

There is a software package out there called XPlanner (http://www.xplanner.org/), which I haven't used yet, but am trying to set up shortly. It runs on Java, JSP, MySQL and is open source. I would love to hear feedback about it from others who have more experience in XP that I do. - DaveSanders

One could write an application to load a Wiki page, parse it, and run it through whatever management/reporting package desired. For example, if UserStories are kept on a particular WikiPage and separated by lines, parse the page for the number of lines; that's the number of UserStories. It's not perfect, but it'd work. -- BrentNewhall

We use a wiki (MoinMoin) because we are a distributed team. We have a project page that has a page for future stories, the current and historical iterations, and a page for completed stories. We use MoinMoin's table feature to list story name, priority, estimate, signup, date completed, and quick comments. The story name is a WikiName that links to the story detail, using MoinMoin's feature for including spaces and other characters in the WikiName.

This is a smaller project (two coders and a UI designer) and our stories are rarely more than the task itself. In addition to the story/task table, the iteration page includes estimated and actual stories, and a daily log. We queue stories in priority order on the future and iteration pages, and indicate when a story is started by "signing up" for it and when it is complete by adding a completion date. Unfinished stories are copied back to the future stories page. -- KenBitskoMacLeod

We were about to use a wiki for UserStories in a new project. Unfortunately, this project was scrapped before we could evaluate it. We used TWiki which has version control of the pages, useful for tracking changes of the stories and also to keep track of which version corresponds to which version of the test cases. TWiki also had useful search features so that people could get a list for all "their" user stories, sorted by priority. (All user stories ended with Story, then TWiki would search for certain keywords in the pages.)

We also played with some scripts that read the pages, looked at keywords and extracted time estimates, status, scheduled release etc into various reports. These reports were to be used for various planning activities. -- SvenRosvall