What’s the difference between Agile Requirements and traditional requirements (using some broad generalizations)?
A couple of key characteristics sets them apart:
- Change handling
Agile Requirements can be expressed in any format using any tool. Traditional requirements are seen as text and models in documents (electronic or physical). But agile requirements can be expressed on a whiteboard, on a post-it note, in a Powerpoint presentation or any other way that helps achieve the purpose.
The purpose of traditional requirements is usually seen as a written description of what should be delivered, in many cases as a part of a formal contract.
The purpose of agile requirements is to facilitate the understanding of what is needed and to help in the discussions on how to fulfill that need.
The challenge with the traditional approach is that it is extremely difficult and time consuming to define exact requirements for software development (normally).
Traditional requirements are created at an early stage, agile requirements are created when they are needed.
The challenges with creating requirements at an early stage are:
- Since we learn as we go along we risk wasting time specifying things that will never get done.
- Since we learn as we go along we risk specifying things in a way that as we go along learn is not the best option.
- We have a negative impact on time-to-market and ROI if we delay release of valuable software.
Challenges with creating them later is that it can sometimes be a bit more difficult to estimate the entire effort early on.
In some traditional schools we have become used to having large requirements chunks. If you have been working with Use Cases you have learned that it is a bad thing to break Use Cases down into smaller pieces (it is called functional decomposition and considered one of the worst sins you can commit when working with Use Cases – it is very common).
Yes, there are different flows in a Uses Case and you may discuss them as such and prioritize them as such – but they they should always be kept in the big Use Case container for documentation purposes (at least in the RUP way of thinking, there are some other flavors of Use Cases as well).
Using an agile approach we try to break things down into pieces that fits well into our Sprints. We slice them functionally and often in a different way than flows in a Use Case.
Challenges with working with big sized chunks of requirements are:
- Might be harder to grasp
- More difficult to prioritize
- Harder to deliver working, valuable, tested software in each sprint
Challenges with working with smaller chunks is that it might be more difficult to see the big picture.
For advice on slicing agile requirements you can read Splitting User Stories.
Traditional requirements are usually created by a few people, for example a business analyst together with the customer, and maybe reviewed by the architect and project manager.
Agile requirements are discussed in the whole team. That way understanding is shared and input can come from anyone on how to best solve a need.
Challenges with having a few people specifying requirements are:
- People get less motivated when they are not allowed to take part of the creative process
- We lose valuable input from the people who often knows our solution options best, the developers of the team. You may argue that requirements are not supposed to specify the solution, and while I agree with this it is utopia to always fully keep the solution out of requirements.
Challenges with having the entire team participate in requirements definition is that it can take a lot of time – especially when you have remote team members.
Traditionally the requirements were meant to capture most of what was supposed to be done. Agile requirements are not seen this way. They should capture as much information as needed to facilitate good discussions and help the team create good solutions to the needs.
Challenges with a lot of details in the requirements are that they might make it more difficult to see the big picture and it takes a lot of time to create.
Challenges with having less detail is that you risk misunderstanding and doing the wrong things.
Traditionally requirements were usually prioritized at the start of the project (when we have the least information). They were sorted into broad groups, for example with the help of MoSCoW. This were done on big chunks, for example entire Use Cases.
In agile development we are constantly re-prioritizing, trying to make sure we do the most important things. We break down requirements into small pieces so we can better understand and prioritize them (for example with the support of User Stories).
Challenges with prioritizing requirements at the start of a project is that it is more or less impossible to set the right priority and a priority to continue to be right after lots of demos and possibly changes in the market or user base.
Traditionally we have learnt that change is inherently bad, because it might impact the holy project plan. It needs to be managed and controlled and preferably kept to a minimum since it creates project risk and extra work. To make changes extra cumbersome we create a process where all changes needs to be approved by a powerful change control board, preferably with people high up in the organization.
In agile we welcome change. Since we know that we will learn more as we develop more and demonstrate working software to stakeholders we see changes in requirements as a good thing that makes us deliver even more value in the product and satisfy stakeholders in a better way.
Challenges with a traditional approach is that it makes it difficult to create the best product we can with the knowledge we gain.
Challenges with an agile approach might be that we introduce change too easily that has unforeseen impact on other teams or products for example.
Traditional requirements are usually living over the entire products lifecycle (ok, well not updated, that rarely happens – but you usually do have some requirements documentation along the road).
Agile requirements are often thrown away after the project. If you are lucky (or skilled) you might have them documented as automated test cases.
Challenges with an agile approach (unless you are good at automated test cases) is that you risk losing a lot of valuable information that later can only be found in the code (which can be both time consuming and risk being misinterpreted).