What happens when your project team wants to become more agile, but you have to keep traditional requirements as a part of your project? Your customer may want to continue using requirements to define their needs, or there may be a bias toward requirements by your management, in the industry, or in governing regulations. Defined Agile processes prefer user stories, and don’t typically offer a role for requirements.
Yet requirements have some advantages in defining a project. They can be more concise and objective, and better form the basis of a contract between customer and team. It can be easier to determine when requirements are met. And they can provide the basis for traceability of downstream artifacts, including test cases, test runs, defects, and source code.
So, how can teams successfully work with requirements and user stories, yet remain agile? They have to work to reduce documentation needs while still maintaining a level of formal requirements for validation and traceability. It’s a difficult problem, but teams are starting to figure out ways to address it. At Swiss Testing Day earlier this year, I asked presentation attendees if any of them worked with both requirements and user stories, and almost a third of the room raised their hands.
I’ve developed a presentation that addresses the use of both requirements and user stories in a blended Agile project environment, and will be giving this presentation at QUEST 2012 in Chicago on May 3rd. My presentation is on Thursday afternoon at 1:00 PM, and is entitled Agility with Traceability: Blending Requirements and User Stories. If you’re at the conference, or thinking of attending, please join me for an intriguing discussion on how to make a requirements-driven process more agile, without losing the requirements. I look forward to seeing you there.
Seapine will also be exhibiting, so if you can only stop by for a little while, check us out on the exhibit floor. I’ll be happy to talk to you further about being agile yet maintaining traceability.