• Seilevel Team

    Here’s the Team

    Welcome to our Seilevel Photo Op.

Agile Requirements Document

At Seilevel, 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.

14 Responses to Agile Requirements Document

  1. Curtis Olson January 26, 2016 at 1:07 pm #

    Excellent description. I’ve been using something similar for years I call the Simple Product Requirements Document. In my opinion, Agile is difficult to initiate on individual projects or with new clients. Waterfall, for all it’s issues, does a good job of defining the scope, priorities and resources (which translates to budget) up front. Most clients want to know that before a project begins.

    Your ARD has a nice balance of defining these things and still allowing for agile (user stories, backlog and sprints) to deal with the lower level requirements.

    Any chance you can post a sample of your ARD?

  2. edward February 12, 2016 at 11:33 am #

    ajay, again a great presentation on the transition from waterfall to agile.

    one of the benefits of creating an ARD you state is “Better prioritization of Features at the outset of the project.”.
    does it have anything that states delivery order preferences or expected value or something to help guide the team in know what to do first?

    earlier in the article, you state that “an ARD will NOT contain the following: * A comprehensive prioritization of Features and Requirements.”

    if that is so, when does the team do the prioritization? and who does the prioritization?

  3. Ajay February 15, 2016 at 11:57 pm #

    Edward, thank you for your kind words. An ARD will usually have a Business Objectives Model that lays out the business problems being tackled, the objectives of the project, expected outcomes and a product concept that defines the key features to be delivered to solve the problems and achieve the objectives. The distinction I make when I say that it ‘will not contain a comprehensive prioritization of Features and Requirements’ is to directly contrast it to a Business Requirements document created at the start of a Waterfall project. Because of its very nature, the planning phase of a Waterfall project is exhaustive, thorough and leaves little to the imagination in terms of what the team is doing and when you exit it. Hence, comprehensive feature prioritization is a necessity of a Waterfall effort and the artifact that conveys it is the Business Requirements document. In Agile, however, prioritization is continuous and changes as business needs change over the life of a project. So, any prioritization that comes with an ARD is at best a starting point and not the end. Prioritization in an Agile project is done by the business owners or their proxy, the Product Owner. The prioritization is literally done at the start of every Sprint to ensure that whatever is planned to be built is indeed correct at that point in time.

  4. Ajay February 16, 2016 at 12:01 am #

    Curtis, thanks for your kind words. Please reach out to our Sales or Marketing Department for a sample of an ARD. And don’t worry, we will respect your privacy and not spam you or harass you in any way thereafter :-). You will control the amount and frequency of our contact with you.

  5. Krishna December 6, 2016 at 5:57 pm #

    Thank you so much for this article, fantastic ideas here!

  6. Hank November 8, 2017 at 2:21 pm #

    Hi Ajay,

    How do I contact the Sales and Marketing Dept to get a sample of the ARD?

  7. David McCreery January 9, 2018 at 5:15 am #

    Ajay, I hope you dont mind me stealing your Idea for a presentation that I am due to do. I’ll let you know how It turns out.

  8. Ajay Badri January 9, 2018 at 1:30 pm #

    Sure David, go for it. I hope you have a great presentation!

  9. Thangamani N August 8, 2018 at 8:12 am #

    Well Summarised, Very Useful Input for Agile Community

  10. Ingrid Gatt December 18, 2018 at 10:47 am #

    How can i find a good template for the agile requirements document ?

  11. Kristine Palmer January 14, 2019 at 12:54 pm #

    Thanks for your interest, Ingrid! This post has been updated to include a link to the sample ARD at the end.

  12. beverly moore February 12, 2019 at 5:16 pm #

    I would like to see a sample of the ARD, please

  13. Marlayna Sullivan June 17, 2019 at 12:48 pm #

    This is a great information. Have you had a situation where you have worked on a project that was done using Agile (or Waterfall) and then future enhancements are implemented using the opposite method? How have you changed/updated/related the information in the ARD to the BRD, vice versa?

  14. Ajay Badri June 29, 2019 at 1:17 pm #

    Great question Marlayna. The ARD is meant to serve as a transitional document for companies making the switch from Waterfall to Agile. It helps organizations move from the structured world of Waterfall to the more open ended, iterative and reactive world of Agile. The shift to Agile is a cultural challenge and the ARD plays a vital role in helping with the cultural transformation / transition from Waterfall. The familiar rituals of creating and reviewing a BRD are maintained, albeit in a much less rigid fashion with the ARD. It takes some time for people to wrap their heads around the notion that an ARD is only a starting point and reflects the best information available to the team at a point in time. This is in stark contrast to the BRD that attempts to define the end state with no better information available to the team than if they were just creating an ARD – a starting point.

    During this crossover period, the ARD behaves identically to a BRD till the team becomes mature enough to create and use ARD in the spirit which they are intended to be used. At the time of the transition, any features and requirements sitting in existing BRD or Change Documents that have not yet been delivered simply move into the ARD to kick off the next phase / iteration of the project. These new features and requirements will form the baseline of the backlog that will be actively managed by the project team going forward. The critical shift here is that the backlog is not sacred, and the team reserves the right to change its mind and reprioritize the backlog or even ditch it and start over as the world changes around them.

    I have not personally witnessed organizations that moved from Agile to Waterfall, so please take my next observations as a best guess on my part. If an organization decides to abandon Agile for any reason whatever and they choose to go with Waterfall, the shift back is relatively straight forward. You would simply go into your existing backlog and take all the unfinished features and organize them into one or more BRD. The rituals of Waterfall development would take over from there and the project (using the BRD as the primary artifact) would start making its way through all the gating processes on the way to final delivery of the finished product.

Leave a Reply

Your email address will not be published. Required fields are marked *