Requirements in agile methodology

On the 12th of February 2001 the Agile Manifesto was published, and after that everything changed regarding how we develop software, impacting how we define the architecture of the platform, we develop or test and, of course, it also modified the approach of defining requirements.

Any mechanism we use to define requirements in an agile methodology should be a tool to bring on a conversation. We can’t write everything, so a level of discussion between the product owner and the team is not only needed, but healthy. The main idea behind the Agile Manifesto is that people are more important than tools or methodologies, one tool can work in one team and not in another, so any approach is valid if it works. The problem with this is that the maturity of the team and company to define their own approach has to be really high and it can bring some problems if we don’t do it properly.

When we are not at that level of maturity, following any established standard like user stories following the “As a, I want, so that” format will help the team to start getting into writing proper requirements, and the same for acceptance criteria. Once the process is there it can be improved with any feedback coming from the team.

Whatever approach we follow, we should always have into consideration the impact of our requirements in the whole process. Not only to develop what we need, but also testing properly or to be able to deliver features often. If the definition of our requirements doesn’t help with the rest of the process, then probably we are doing something wrong.

Requirements and testing

We have all seen the test pyramid (or triangle) a lot of times, it is an extended agreement that you need to move tests down as much as possible to have a healthy balance in your tests. What is not mentioned so often is the impact that having requirements properly split in small functional increments has in how we test the platform.

When we have a small story, with a limited scope and limited number of acceptance criteria, the tests that need to be written tend to be associated with a small part of the platform and, hence, it doesn’t require a complete end to end flow to be tested. Naturally we will be moving those tests down into the pyramid. Reviewing acceptance criteria and defining in which level that test has to be automated is an important part of the sprint planning or any other meeting when we analyse stories.

Incremental development

Almost all companies implementing any agile methodology aim to deliver new features in production, if not on a daily basis, at least as often as possible. The only approach to achieve having releases that often is following incremental development. 

Splitting requirements in small increments with a business value is one of the biggest challenges I found trying to implement continuous delivery. Changing the mindset of a team is always something that takes time and requires a lot of trial and error.

There are different strategies to break down the requirements until they are small enough, we need to find which one works better for us or for a particular feature we have to implement. Practice brings perfection, the only way to be able to break features down into proper stories is trying. It is important though not to split along architectural or technical boundaries or we will end up having stories that don't add any business value to the system.

Another question is, when is a story small enough? Again, it depends on the team, but there are some rules that can help:

• A story shouldn’t take longer than half a sprint for two people.
• You don’t have a long list of acceptance criteria. It depends on how teams define them, but having more than 5-6 can be a sign of a big story.

In all the agile transitions I’ve been a part of, defining requirements in a way that supports the process is probably one of the points that took longer. If you are not methodical with the approach of breaking down the requirements it is really easy to end up having stories with no business value. Bringing that knowledge to the team hiring Product owners with experience and training to the rest of the team is critical to succeed in any transition to an agile methodology. Only with good requirements we can’t achieve our goals, but it is a big step forward in the right direction.