Four Ways To Improve Agile Requirements Management
One of the challenges of Agile projects is ensuring that the requirements remain “Agile”. While requirements are not necessarily neglected on Agile projects, an Agile project may erroneously take a waterfall approach to requirements.
Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .
1. Communicate Requirements Often And Effectively
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.
Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.
If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.
Established method: Email discussion
Suggested method: JAD, daily stand –ups
2. Use Collaboration Tools For Requirements Management
“Business people and developers must work together daily throughout the project.”
This is related to the other “C”—Communicate.
Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.
Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.
If possible, include collaborative tools like wikis and discussion boards as part of your website.
Established method: Word documents attached to emails
Suggested method: Wiki/Web page with automated change notification
3. Add Models And Wireframes To Your Requirements
“Continuous attention to technical excellence and good design enhances agility.”
If applicable, use wireframes or mockups with callouts as a supplement to your requirements.
This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.
Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).
Established method: Design document/specification; Text-only documents.
Suggested method: Internally-hosted website with wireframes and bulleted descriptions
4. Keep User Stories Simple
“Simplicity--the art of maximizing the amount of work not done--is essential.”
Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.
Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.
Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.
Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.
Established method: Large document which describes many features
Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.
Here are some simple techniques to adapt your requirements management effort to an agile project. The quotes at the beginning of each section are from the “Principles Behind the Agile Manifesto” at http://agilemanifesto.org .
1. Communicate Requirements Often And Effectively
“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
Two problems with email is that it is inefficient and easy to ignore. Email thread discussions can be long, tedious, and annoying. Despite the advances in emoticons over the past several years, it is also impossible to interpret non-verbal communication in email.
Resolutions to discussions around requirements, scope, and implementation will be resolved much quicker and to the satisfaction of more stakeholders through a meeting or hallway conversation.
If moderating a large number of email discussions is part of your current requirements process (for example, after the initial draft of the requirements doc is published), perhaps it’s time to schedule regular meetings at key points during the release cycle.
Established method: Email discussion
Suggested method: JAD, daily stand –ups
2. Use Collaboration Tools For Requirements Management
“Business people and developers must work together daily throughout the project.”
This is related to the other “C”—Communicate.
Communication on a project should be visible to all stakeholders in the project. Changes to requirements should be pushed out quickly and universally, without having to remember whether the developer who started last week is on the dev@mycompany.com mailing list.
Manage requirements in a central location where all stakeholders have immediate and easy access. An internal website for requirements and product management information is a much more efficient way of reaching your audience than emailing copies of documents to your stakeholders.
If possible, include collaborative tools like wikis and discussion boards as part of your website.
Established method: Word documents attached to emails
Suggested method: Wiki/Web page with automated change notification
3. Add Models And Wireframes To Your Requirements
“Continuous attention to technical excellence and good design enhances agility.”
If applicable, use wireframes or mockups with callouts as a supplement to your requirements.
This is especially useful on projects which call for enhancements to existing interfaces. A wireframe with brief text descriptions is easily consumable, and conveys a large amount of information very efficiently.
Include more detailed descriptions of wireframes and mockups in your user stories, and publish it on your internal product management website (see #2 above).
Established method: Design document/specification; Text-only documents.
Suggested method: Internally-hosted website with wireframes and bulleted descriptions
4. Keep User Stories Simple
“Simplicity--the art of maximizing the amount of work not done--is essential.”
Ensure your user stories describe one and only one feature, and only the functions necessary for that feature.
Looking through a large, monolithic document which describes multiple features to be implemented across several releases wastes time.
Breaking your user stories down into descriptions of the most basic functions required for a feature also helps maintain release discipline.
Resist the temptation to include requirements for “nice to have” or “future” functionality. This clutters the user story with unnecessary information.
Established method: Large document which describes many features
Suggested method: Wiki page/website with a single page devoted to a single feature. Include links to related features.
Labels: agile, agile requirements, requirements management, software requirements
posted by Talmadge at 5/28/2008 02:27:00 PM
1 Comments:
I like using video conferencing when discussing, sizing and estimating before committing. We also have used IM as back channeling tool when planning to support collaboration.
I posted an interview with Ellen Gottesdiener covering agile requirements (Software Process and Measurement Cast www.spamcast.net) that dovetail very nicely with your post.
Tom
Post a Comment
<< Home