Do “Agile” Projects Need Written Requirements?

Do “Agile”projects need written requirements? Let us answer this question in this short article.

As you may know, more and more software development teams have been adopting “Agile”processes over the past decade or so. As you may also know, Agile development processes such as Scrum and XP emphasize “working software” over requirements documentation.

Does this mean detailed, written requirements should be avoided in Agile projects?

Agile vs. Detailed Requirements Documentation

As explained at the Agile Manifesto website, “Agile” is about “better ways of developing software.”

Agile Manifesto includes 4 items:

1. Individuals and interactions over processes and tools.

2. Working software over comprehensive documentation.

3. Customer collaboration over contract negotiation.

4. Responding to change over following a plan.

Many Agile software development teams interpret point #2 above to mean something along the lines of “detailed requirements are the enemy of Agile.”

Is this interpretation really correct?

User Stories

Agile processes recommend you to document requirements on index cards or sticky notes (i.e. just a line or two) in the form of very short “User Stories.”In addition, many Agile processes also recommend that you shred the index cards at the end of each “Sprint.”

A “User Story” is a very short description of a feature written from the perspective of a user. User stories are the key requirements artifacts in Agile projects, and typically follow a simple 1-sentenceformat such as:

As a [type of user], I want [some feature] so that [some benefit].

Here is a practical example of a user story for a CRM system.

As a sales manager, I want a weekly pipeline report so that I can track the performance of my salespeople against their quota.

Shortcomings of Just Using “User Stories”

While user stories are short and easy-to-read, many companies find that they suffer from one critical shortcoming:

It is hard to document detailed requirements(both functional and non-functional) via just user stories.

This is especially true for:

• Complex products/projects

• Products/projects with many dependencies

Agile processes recommend using face-to-face conversations to replace detailed,written requirements. However, many companies find this to be impractical for:

• Stakeholders located in different cities or countries

• Teams that outsource a part of their project

As a result, many companies have found that the “face-to-face conversation as a replacement for detailed requirements” approach does not scale for large-scale or complex projects.

Too Few Calories- Good or Bad?

While the Agile Manifesto correctly points out that having too much documentation is bad – I believe that many Agile teams incorrectly interpret this to mean all documentation is bad(unless they can be written on index cards).

To use an (albeit imperfect) analogy:

This is like a nutritionist correctly observing that too many calories are bad – and then incorrectly concluding that all calories are bad. The fact is, without consuming enough calories we humans cannot survive!

Similarly - without enough requirements documentation,complex projects cannot succeed.For most companies that undertake complex projects, user-stories-on-index-cards certainly isn’t enough requirements documentation.

Furthermore - lack of detailed, written requirements also leads to other problems:

• Implementing enhancements is much harder, as thorough written documentation of what has already been implemented does not exist.

• No audit trails are present for compliance or quality control.

• Personnel turnover in project teams causes much severe disruptions.

•  Creating & managing test cases is much harder - except for collocated teams working on simple applications or small projects.

So, Is Agile Unfit for Complex Products/Projects?

So far I’ve made a case for creating detailed, written requirements – especially for complex products/projects.

Am I saying you should avoid Agile for complex projects?

Au contraire!

In fact, I believe most (although not all) of the complex projects can benefit from Agile processes. That’s why I recommend the following.

Best of Both Worlds

I recommend using detailed requirements and Agile processes together for complex products/projects. To some, this may sound like heresy.

But it really isn’t! I believe many Agile teams trip themselves up by failing to realize one crucial distinction:

User stories do NOT replace detailed requirements. Rather, user stories are best used as pointers to detailed requirements.

When properly utilized -Agile processes (Scrum, XP, etc)together with detailed requirements can help you tap into the best of both worlds. In such an approach:

• Agile user stories point to detailed requirements – which themselves are written iteratively.

• Product Owners (PO) manage sprints using user stories.

• BAs write the detailed requirements to which the user stories point to.

Many companies have found that such an approach scales well to even complex, large-scale projects.

For more details on how you can use Agile processes and detailed requirements together – refer to the free eBook, A Practical Guide: Business Analysts & Agile Development. It also offers practical tips onhow BA teams can work most effectively with Agile development teams.

Author: Michael Shrivathsanhas requirements management experience spanning two decades at successful software companies in Silicon Valley, USA. He is the VP of Product Management at Accompa, the company behind the popular requirements management software used by Business Analysis, Product Management, and related teams– for Agile, traditional/waterfall, as well as hybrid projects.

References:

1. A Practical Guide: Business Analysts & Agile Development–FREE eBook that offers practical tips on how BAs can work most effectively with Agile development teams.

2. Free Trial of Accompa – cloud-based software to manage detailed requirements for Agile, traditional/waterfall, as well as hybrid projects.

3. Requirements Management Software by Accompa – website where you can find out more information about Accompa cloud-based software.