Manage Learn to apply best practices and optimize your operations.

Does Agile use business requirements documents?

How does managing requirements differ in an Agile environment versus a mixed-methodology environment? How do Agile project managers document business requirements?

Some use the term requirements management to mean the full requirements process, including identifying business...

requirements and evaluating their content. In my humble opinion, it is more appropriate to restrict the phrase requirements management to the mostly mechanical administrative activities of capturing, categorizing, keeping track of and controlling changes to requirements.

The two aspects do interact, and how they interact is especially relevant for the way Agile requirements are documented. In Agile, the product owner or customer representative typically defines requirements with user stories. A user story very briefly describes something of value to a user or customer and traditionally is written on an index card in the form introduced by Mike Cohn, "As a <type of user> I <want/can/am able to/need to/etc.> so that <some reason>." Some teams also include their user story acceptance criteria (brief descriptions written on the back of the index card of how to tell the user story has been met) in the user stories.

Non-Agile development also documents business requirements definitions. Non-Agile teams could, but usually don't, write them in a user story format yielding one requirement per index card. Initial business requirements documentation formats are not terribly critical for distinguishing between Agile and non-Agile. What happens afterward, though, tends to differ widely between Agile and non-Agile development.

A non-Agile group generally keeps track of all the written requirements throughout the duration of the project and captures written expansions/modifications of them. This process drives the business requirements document down to greater detail or otherwise clarifies them. Non-Agile often actively controls prospective changes to business requirements documents with a change control board or similar body. This body pre-approves requested changes and sometimes also confirms approved changes have been made as approved. Those non-Agile projects that use automated requirements management tools often cross-reference each requirement to where it is used in order to create a traceability matrix. Such a matrix helps confirm that each requirement has been addressed and that development is not creating artifacts that don't tie to requirements.

Next Steps

Have more software quality questions for our experts?

Check out our recent expert responses.

If your answer's not there, submit a new question.

Dig Deeper on Topics Archive

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

What are your thoughts on Agile requirements documentation and management?
I am new to Agile, this may be the reason why I can not imagine a Project whith no clear BRD and scope controll where the Developer plays the roles of coder and IT Business Analyst. To me it sounds as a joke.
In my opinion in Agile the business spécifications are replaced by the tests. As they are writen before starting to implement the actual code, they are a different form of spécifications.
While I agree that a lot of time can be wasted tracking requirements (non-agile) and like the user story approach, there are many things that could possibly go wrong with no requirements management.
If a project has more than just a few people involved, some communication is needed and changes will also need to be communicated - lest one user re-interprets a need/story that negatively affects another. Also, if a project is being funded by a business group, they will expect to have their needs met and will want some traceability (I realize this can be at odds with pure Agile, but it is reality in many business applications). Let the developers and users work closely together, document user stories with little overhead, but some level of change monitoring will be needed beyond the first sprint or two.
Agile is very good in environments, where you can turn up the entropy dial to do small incremental experiments with software.   Some people might still use requirement documents, but they may not call them that.  Maybe User Stories and Acceptance Criteria.  
Our approach is to use our backlog of test charters and their associated criteria of satisfaction as a sort of requirements repository. We started running into scenarios where new user stories were being written and implemented that unknowingly broke existing functionality or contradicted previous stories. When we spoke to the team about it, it turns out that they weren’t keeping any documentation on implemented features, and were discarding the user stories once they were complete. We shared out backlog of test charters with them, and have been having much better success with our development efforts.
There is a wide amount of latitude that can be applied to this question. Overall,the goal of Agile documentation is to provide "just enough documentation" to be workable and to produce a "minimal viable product", which then allows for incremental and regular update, improvement and refactoring. How that is applied will vary dramatically in different organizations. In mine, we create relevant and actionable tests that we can verify, enough to determine that the feature works, but not s much as to straight-jacket its development, implementation or testing. What we do may be seen as too little for some organizations, and too much for others. What matters, though, is that it provides enough for our various development activities to communicate and create effective software.
Thanks everybody for these great responses. Please keep sharing.
Reduced waste project documentation and traceability is an age old challenge.  We have helped a number of clients, particularly medical device companies, apply lean and agile methods to product delivery. Impact mapping, Discover-to-Deliver, story mapping, among others, has been applied to document and trace a products progress from conception to end-of-life.