SCRUM and DOORS

Tony_Goodman - Wed Mar 25 05:36:52 EDT 2009
Some cynics might say that agile project management used to be called "lets hack together what we can in as little time as possible, and if it doesn't work we will fix it next month", but I couldn't possibly comment.

I have used DOORS together with scrum.
Keep your requirements model and use cases because you still need some control over what you are doing and you will need something to verify your system against.

Create a project backlog that contains stories. These can be linked to requirements and use cases.

Within the backlog, you prioritise and assign stories to sprints/developers. DOORS is good at this because you can use attributes filters to get the views you need on the data.

I found that the project backlog got big very quickly and became a little cumbersome to manage. This can be mitigated by spending time to organise your stories in a meaningful manner. i.e. don't have a flat list.

There was also a bit of an overhead in keeping the backlog up to date due to the rapid lifecycle of stories - we were on 2 week sprints.

Make sure you use integer type attributes for size points, priorities and sprint numbers (if you use strings then sorting and summation is difficult).

The most important thing to remember is that scrum gives you a different approach to handling what you are going to do in the short term - you still need to keep a grip on your requirements to manage the project in the long run.

Best of luck.

Miamc - Tue Apr 07 14:39:45 EDT 2009
Thank you very much Tony.

I've been wrestling with the apparent conflict between swift, light, user stories, and the sort of "real" requirements that facilitate understanding between the business and the coders (and, yes, it's a written contract of sorts, which seems to be anathema to SCRUM). My gut instinct matches your advice -- you don't throw out the requirements model in favor of the stories. And my group has invested a lot in understanding, developing, and managing that requirements model (and -- personal plug here -- I'll be presenting about it at the UGC in June).

I'm all for the notion of discussions between the business and the engineers in order to clarify the requirements, but no matter how short the sprint I don't believe the coders will remember all that was agreed upon if you don't document it. And I just don't see test cases as a rational vehicle for gaining understanding about what a system does if you're new on the team, or a new stakeholder.

We're working on integrating DOORS with TFS. I can envision linking the requirements in DOORS to the user story backlog managed in TFS (there's an add-on we're likely to use). So I'm not sure we'd even have the user stories in DOORS, although I set up a formal module to play with the notion.

I'm leaving this question as unanswered just to encourage any others to offer their thoughts.