5 Essential Agile Techniques to Improve Your Requirements Documentation

In this article, you will find agile techniques that play an important role while creating requirements documentation. You will also find solution to handle the inefficiencies in  rigid traditional requirements gathering process. Also learn that how to gather requirements in agile!

Why does Agile play a big role in requirements?

Debatably, one of the biggest challenges in software projects is producing effective requirements. When the requirements aren’t done the right way, there is a high chance of having an unstable foundation in the product lifecycle, which often leads to an unsatisfactory end product. In most traditional projects, the requirements team has a mental barrier between them and other teams. This mental barrier isn’t intentionally created, in-fact, it is more of a cultural issue. Agile techniques play a key role in transforming that closed culture.

Software projects fail when the act of creating requirements becomes solely the requirements teams’ burden. Commercial software products or systems typically evolve at an exceedingly fast pace due to highly competitive markets. A side effect of this fast pace is that the requirements documentation often seems out of date and irrelevant if created using traditional methods that simply can’t keep up the pace. One of the worst feelings as a project team member is seeing your requirements struggle to keep up with the pace of the changing environment. It can be pretty demotivating for the entire team. Agile techniques in requirements gathering can not only help overcome these issues but can also help build a higher quality end product.

At the heart of Agile requirements is…

The aforesaid conundrum is a substantial one but before we jump into discussing the solutions, it is important to understand the basics of Agile requirements.

Agile requirements come in many shapes and forms, but the most common form is a User Story. Let’s understand what a User story is all about.

User Stories, or stories as some might call it (or them), represent customer requirements in a simple written narrative rather than a tedious comprehensive document. It drives forward conversations within Agile teams for planning and estimation. They contain a number of criteria that can be used to determine when a User Story is considered to be complete. A good narrative for a User Story would be something that adds value for the customer, partner, consumer, or stakeholder.

Several stories make a Product Backlog and ideally the whole Agile team is responsible for the health of the Product Backlog. However, a Product Owner (PO) is appointed to serve as the single wring-able neck if something goes wrong with the end product. A dangerous yet common misconception in the Agile world is that the PO is the only person responsible for the Product Backlog which I’m afraid is the root cause of many failed products.

5 Agile Techniques to Improve Requirements Documentation:

1. Compliment User stories with supporting artifacts

In cases where a User story does not have enough detail you may attach use cases, traditional requirements or decision tables. In some situations, a client may demand for more documentation, especially while dealing with organizations that get audited for process compliance for e.g. CMMI. This approach may work out well in that scenario.

2. Create requirements that slice the cake

The best way to do this is by writing end to end User Stories which include smaller feature sets, rather than writing stories that are split across technical boundaries. Splitting stories along technical boundaries creates dependent stories which fails the INVEST principle, which is described below. When writing stories, think of slicing a multilayered cake where each layer represents a functional area of the product. For e.g. front end, middleware, backend, database and so on.

3. INVEST in your User Stories

An ideal User Story would have the following characteristics: Independent, Negotiable, Valuable, Estimable, Small and Testable. This is called the INVEST principle. Make stories as independent as possible. Avoid using stories as written contracts, they should be negotiable. Make User Stories valuable to the user and consumers. A story may not be estimable if the implementers lack domain knowledge or technical knowledge. POs and technical leads need to help the implementers gain the domain and technical knowledge by writing effective user stories which follow the INVEST principle that cause conversations focused towards implementing the User Story. Predefined test criteria should be mentioned in the done criteria of an ideal User Story. POs should take testers’ guidance for this and testers should be proactive in guiding the product owners.

4. Groom your User Stories often

Conduct User Story grooming workshops daily or weekly depending on how soon you need results. I remember being a part of these workshops during my career as a software developer and I can’t tell you how valuable it was. It can be implemented by following these steps. First, brainstorm stories on a whiteboard, then organize them into their user themes, prioritize the stories into high, medium and low and lastly improve high priority stories and make them follow INVEST principle.

5. Don’t be afraid to create prototypes

It is better to spend a small amount of time in building prototypes to just test out the waters. This really helps in bringing ideas to reality and encourages healthy discussions. However, make sure the prototype does not turn into a bulky project and build it so that it can be used in some useful way in the actual  product.

What if I have a rigid traditional requirements gathering process?

If you write your requirements using the guidelines mentioned above you should definitely see good results even if you are following a fairly traditional requirements gathering process. The key is to introduce these techniques one step at a time and be patient. However, if you feel it’s highly challenging to create change in your organisation, no worries, it is never too late to start casual conversations about Agile techniques.

Let’s assume there is no User Story grooming process occurring in your project. In this scenario you would want to bring in the grooming process gradually. Before you organize a full blown grooming session have an informal conversation with your team about conducting a User Role Modelling session with your Agile team.

If you explain the benefits clearly and implement it in a lightweight manner there is no reason why they would resist. After the initial set of User Roles are identified, your team can start rewriting the existing requirements using INVEST principle for the identified User Roles.

Recap

1. Ineffective Agile Requirements most often lead to failed products
2. The most common form of Agile requirements are User Stories
3. Compliment User stories with supporting artifacts, write well rounded User Stories by slicing the cake, INVEST in User Stories, conduct User Story grooming sessions weekly or daily depending on your needs and create prototypes to compliment your requirements
4. If these processes are new to your team you can start by talking to your team about the benefits of these processes and then introduce these processes gradually.

It is never too late to implement these Agile Requirements best practices. If you fear that this would slow down your team then implement these processes in smaller chunks until you see actual valued results.

Remember that introducing these changes may seem risky but the biggest risk is not trying at all!