At ArgonDigital, on our Agile projects we have introduced a project artifact called the Agile Requirements Document or ARD that we create during the planning phase of a project.  We have done this on several projects and have had good success with it.  An ARD is conceptually similar in some ways to the classic Business Requirements Document or BRD that many of the readers will be familiar with.

The BRD is typically used in Waterfall or Iterative projects.  It describes the business needs of the users sponsoring the project and lists the requirements from a business perspective that must be delivered by the IT team.  In many organizations, it is a contract of sorts that the Business users enter into with their IT counterparts.  It defines the desired business outcomes that will be achieved in terms of specific problems that will be solved and benefits that will accrue to the organization as a result thereof.  It also contains a prioritized list of features and business requirements that the delivered software must provide.

Like any contract entered into between two parties for any purpose whatsoever, the contents of the BRD are negotiated in terms of scope, the features the be delivered, the specific requirements that go into the definition of a feature, when it will be delivered and the specific systems that will be built or modified by the project.  These negotiations are often intense because at some fundamental level, the two sides understand that they are indeed entering into a binding contract with each other, even if a BRD is not explicitly defined as such.  When a BRD is complete, there are typically official sign offs provided by representatives of Business and IT.  Once that is done, the planning phase is typically complete and the IT team goes off to build the software they have promised to deliver.  The next time that Business and the IT teams meet will be during the User Acceptance Testing Phase or UAT when the business team tests the delivered software for compliance with the contracted deliverable defined in the BRD.

If all this sounds hidebound and legal, it is because that is what it really we are really dealing with here.  In a classic Waterfall project, there is a buyer and a seller.  Business is “buying” software from the IT team.  The BRD is the Terms and Conditions document.  At the end of the project, if Business signs off on the UAT, then the promised product has been delivered and the purchase contract is deemed to have been fulfilled.  If, as often happens in Waterfall projects, the UAT goes badly, then we have a broken contract with all the accompanying fallout, teeth gnashing, finger pointing and recriminations that accompany any venture gone bad.

Which brings us to the ARD.  I have gone to great lengths to define the role played by the BRD in a Waterfall methodology, so that it will be easy for me to define what an ARD is, largely by contrasting it with a BRD.

First off, let us look at the purpose of an ARD.  It is a means to create the initial product backlog for the Agile team in a systematic manner.  Like a BRD, an ARD will contain the following:

1. A project charter that defines why the project is being undertaken.
2. A clear definition of the business problem being tackled, objectives and desired outcomes that are quantified and measurable.
3. Any and all models needed to bound the project scope and provide context to the request deliverables.
4. A Product Concept that defines at a high level the deliverable(s) to be created to solve the business problem and meet the project objectives.
5. A listing of Features that flesh out the Product Concept in greater detail.
6. Some User Stories or Use Cases that give additional context to the Features.  An exhaustive set of User Stories is not created at this time.  We focus more on the Epic Stories for key features to be built.
7. And that is it.

Unlike a BRD, an ARD will NOT contain the following:

1. Detailed functional requirements that define the Features at a granular level.
2. Detailed non-functional requirements that must be satisfied by the product as a whole or specific features / requirements.
3. A comprehensive prioritization of Features and Requirements.
4. Any specific definition of exactly when the project as a whole will be delivered.
5. A formal sign off from an list of approvers from Business, IT, Testing and so on.

The Features defined in the ARD are fed into the Product Backlog and constitute the starting point of the project.  Once the Features are loaded into the backlog, all of the standard Agile methodologies kick in.  Features are prioritized in the Product Backlog, selected for development during a Sprint cycle, sized, defined with User Stories and Acceptance Criteria, developed, tested, delivered and deployed.  At the end of each Sprint, Features are re-prioritized, added, deleted, changed and so on.  Simply put, the initial Product Backlog that comes out of the ARD is not inviolate or sacred in any way.  Everything is subject to change and modification as dictated by changes in the world around the team working on the project.

This is not to be misconstrued that the Product Backlog coming out of the ARD is some random collection of Features that get fed into a blender that then proceeds to make mincemeat out of it.  Our experience shows that a carefully crafted ARD at the beginning of the project actually cuts down on a lot of churn once the Sprints start in earnest.  Unless there is some fundamental change in either the business priorities or project resources, there is not much change to the actual features defined for the effort.  There is also a much higher reduction in the number of critical features that were missed altogether when the initial Product Backlog is created.

The creation of the ARD and systematic definition of Features going into the Product Backlog has led to the following tangible benefits for the teams using this approach.

1. A much better understanding of actual Project Scope.
2. Better resource planning.
3. Better prioritization of Features at the outset of the project.
4. Much stronger buy in from Business Partners, for many of whom this was their first Agile project.
5. An much better way for new Business, Development and Test teams to ease into Agile methodology than dropping them into a Sprint cycle with little or no context.
6. A frame of reference that the teams can go back to while they are in the middle of the project to see if they are still on track with what they set out to do initially.

We are advising all our Clients to start using ARD on their Agile efforts.  I would strongly urge you to consider doing the same on your efforts. To help you get started, download our ARD Template now.