How Agile teams can better manage requirements

In the context of Agile, a requirement is a statement of need or want. It’s typically framed by the user - or at least the business’ understanding of the user - and shaped by commercial goals. Naturally, they are absolutely essential in the delivery of any product or service.

There are many different approaches you can take to managing requirements. What matters, though, is that the work that needs to be done is done and to the quality and specifications required.

However, managing requirements isn’t always that easy. If you blur and combine different management techniques, for example, you will likely lose clarity and control over the requirements you’re trying to juggle. Inevitably, the consistency and quality of your work will wane if this happens.

The best way to give requirements the consideration they need is to answer three key questions:

• How should requirements be captured?
• Who is responsible for them?
• What happens when business priorities change?
  
  

In this post we’ll look at each of these questions and offer ways of answering them. This will be crucial in helping you to ensure requirements are always managed effectively and responsibly.

How should requirements be captured

Requirements can be captured in many different ways. It can be done via business or functional requirements, use cases or user stories.

There are lots of options, but which is correct?

Though many will have a bias to what they are used to doing, the truth of the matter is that there’s no right answer. It comes down to what you’re trying to deliver.

User stories tend to work best for Agile software development. This is due to the fact that they’re small pieces of work, defined from a user's point of view and written as “short, simple descriptions of a feature, told from the perspective of the person who wants this new capability, usually a user or customer of the system”.

Because they’re small with ‘enough detail’, this drives the need to collaborate to ensure a thorough understanding of what’s required. You could say that user stories are "a promise to have a conversation with the onsite customer" as Alistair Cockburn put it in 1998.

Do they always need to be user stories?

However, if the work is being done from a purely technical perspective, don’t feel you need to fit this into a user story, as often there is no value in this.

A technical task in isolation generally has no real value to an end-user and is normally an enabler for a follow-up user story, so spending time trying to fit into this format could take more time than actually completing the task.

Who should write them?

This isn’t an easy one to answer. As an Agile coach and former product owner, I often get asked “who writes user stories?” as if they should be captured by a specific nominated job role. You don’t, of course, need permission to capture user or business needs.
In a sense it’s a victim of one of the virtues of agile: collaboration. Ultimately anyone can write up requirements in whatever format you’ve decided is right for you.

The best approach, in my experience, is for everyone in a team to write up requirements. This will help build a shared understanding of the product backlog.

Who is responsible for managing requirements?

Although anyone can write up requirements, there’s a single owner for managing them: the product owner. Once something is in the backlog, the product owner is responsible for deciding its value and prioritising them appropriately.

When this doesn’t happen and a Product Owner isn’t properly empowered, it can cause lots of issues. It invites too many opinions from across an organisation, and can lead to questionable approaches to prioritisation. It will inevitably cause delivery timelines to slip, and what’s delivered probably won’t deliver the value the business expects.

Empowering the product owner

An empowered product owner - who drives the product vision and ensures the highest valued work items are prioritised - will lead to a fully autonomous and happy team. That’s what every Agile team should be aiming for.

However, it’s important for everyone to remember that the product owner doesn’t know everything. While they are sometimes referred to as the ‘CEO of product’ (perhaps a little unhelpfully) product owners don’t have all of the answers; they never make priority decisions in isolation, but instead by synthesising inputs from everyone around them.

What happens when business priorities change?

The Agile Manifesto states that teams carrying out software development should ultimately value "responding to change over following a plan."

This is no less true when it comes to managing requirements.

In today’s ever-changing world circumstances change and things move on. Priorities will inevitably change. But how should Agile teams deal with this state of affairs?

Successful teams adapt and pivot when they need to. There is an expectation on the product owner that, where possible, it's better to keep changes outside of a Sprint.

However, where this can’t be avoided, the team should engage in open and honest conversations among themselves about what's possible. This should then result in a ‘negotiation meeting’ - mid-sprint - with the product owner to discuss trade-offs, based on the value of the proposed work.

Remember, one of the basic premises of Agile is to ensure you’re delivering the ‘highest value’ work during a sprint. If the team isn’t able to respond to change and pivot, is really this being achieved?

Final thoughts on capturing requirements

There are no hard and fast rules on how an Agile team should manage requirements. It really does depend on circumstances and the team.

What matters though is that these issues are discussed, and that solving them is a collaborative process. That way, you can manage the requirements the way that best suits the team. Delivering value to the business should always be the priority; the easiest way to do that is by finding a way of working that everyone is comfortable with.

Adopting this flexible and ‘Agile’ mindset, adapting to changing circumstances and having an empowered product owner will really provide both you and the team with the ability to continuously improve and deliver high-quality software. In essence, that’s exactly what an Agile delivery team should be doing.