How can we possibly deliver this feature if the requirements keep changing all the time!??
We’re all familiar with the theory: one of the principles behind the Agile Manifesto is to welcome changing requirements, even late in the development. This is one of the biggest distinctions between being agile and taking a more traditional approach to project management.
Changing requirements can cause a lot of frustration
In practice, it can be a lot harder to enthusiastically embrace how our goal posts keep moving. The reasons for this hesitation can be many:
- The need for rework. We may have implemented the functionality already, based on the original requirements, either completely end-to-end or partially by taking it into account when implementing, let’s say, an API. Changing it now makes us feel as if we have wasted our time and effort.
- Knock-on effects. Upcoming items in the backlog might assume that this feature behaves in some specific way and changing something will require us to update and re-estimate a lot of backlog items.
- We had set aside a certain amount of time (money) to build this feature and making changes means we need to go back to the customer and ask for more money or swallow the cost ourselves. And if we allow this change now, what’s to say there won’t be a lot more coming? I’ll return to agile contracts in a later blog post but in the meanwhile, let’s just say that fixed price, fixed scope contracts make it very hard to be agile.
- Misunderstandings and lack of communication. It’s no good changing a requirement if people aren’t made aware of the change, particularly those implementing the feature or confirming that it behaves as expected.
- A lack of a clear picture. Many people find it reassuring to know where we are going and where we are. This could apply to the client but also the members of the team.
- Evolving architecture is not trivial. To come up with a suitable technical architecture for the system we’re building, we need to have a sense for where we are likely to end up. If the requirements change drastically, the decisions we made early on may no longer make sense.
Why not just lock down the requirements and get on with it?
So, there seem to be a lot of arguments against allowing requirements to change. Unfortunately, if we build blindly to our initial requirements, the only thing we can be reasonably certain of is that we’ll be building the wrong thing. Delivering what we thought was the solution or what the customer thought they wanted can be extremely wasteful for everyone involved.
We will never know as little as we do right now
The most important reason why we need to let requirements emerge and evolve is that, regardless of how much we think we know at the start, we will learn a lot more about the problem we’re trying to solve and the suitability of our solution along the way. If we have a way to act on these insights early on, while we’re still developing the solution, it will be a lot easier and cheaper than to do it later.
Best case, we realise that there is an easier way to solve the problems for the users or that by making some addition, the solution will work a lot better for them. Less ideal but just as important, it may turn out that what we thought was an important requirement is a lot less important and something else we hadn’t even considered would make a huge improvement.
Predicting software development is notoriously hard
The time we’ve set aside in our planning for implementing something tends to be based on some kind of estimate (i.e. a guess) and in reality, that estimate is often wrong. The reasons are many.
Often, we come across some unexpected technical challenges or (much less ofthen, in my experience!) we realise that things are easier than we thought. Changes to the team may also affect how much work we can get through. Perhaps someone on the team falls ill, is pinched by another project or goes on a nice, long holiday.
Unless we have the luxury of having no urgency to deliver (which should make us question whether we should be doing what we’re doing at all!), we need to act. Are there any requirements we can drop and not implement? What is the effect of doing so; do we need to change any of the remaining requirements? Knowing what we know about the technical implementation, are there requirements we can tweak to make the implementation easier to complete? Etc etc.
Sometimes, it’s not just our own understanding that changes. The world around us may change too, rendering our requirements out of date. It would be some new legislation getting introduced or a competitor launching a new product or feature, so that our customers would suddenly expect something different. Or our own organisation changes in such a way that a new group of users will start using or administrating the system (or the problem we’re trying to solve is no longer relevant).
It would be silly not taking these changing conditions into account and build a solution based on how the world looked 3 or 6 months ago!
Signs we’re not agile enough about our requirements
There can be lots of signs to look out for that may indicate that we’re not agile enough when it comes to requirements:
- Specification documents. Hopefully, this point is too obvious to include in the list but I have seen it happen: if we have an extensive, version controlled and signed off specification, how could we possibly be agile?
- Limited contact with the customer/users during development. This means we risk either missing out on possible improvements (“I can see that it would be a lot more useful to do it that way but this is what we have agreed with the customer”) or making the wrong assumptions about the suitability of changes and compromises. Often, this issue goes hand in hand with the infamous “This is not what we agreed” or “This is not what I had in mind” at the end of the project.
- “We’re done with this feature”. Moving on to the next feature is often the right thing to do but in other cases, when we ignore a valuable improvement staring us in the face just to move on to a less important item in the backlog, we miss an opportunity.
- A very detailed product backlog. Yes, that’s true! If the whole backlog has been broken down into granular user stories, complete with acceptance criteria, ready to bring into development, that backlog is no better than those old-school specification documents. Once we’ve put all that effort in, we may either be reluctant to change the requirements or we will have wasted a lot of time writing user stories and acceptance criteria we will end up throwing away when requirements change.
How do we make changing requirements work to our advantage?
It’s hopefully clear by now that we need to avoid the big specification document, but what do we do instead?
1. Let requirements emerge and evolve
The good news is that if we follow a normal standard backlog format, we’ve got a good tool already: our backlog. The top few stories, which we’re likely to be working on within the next few weeks, should be well understood and granular enough so that we can bring them into our next sprint (or onto our Kanban board).
Stories further down the backlog, should be less granular. Note “should be”, not “might be”! The further into the future we’re likely to implement something, the less time we should spend specifying it. Chances are the requirements will have changed by the time we get to that story anyway.
If we get to that story and it is still relevant.
2. Focus on shared understanding and collaboration
Rather than telling the team “do a, then b, then c”, involve them (or at least a few representatives) in the discussions around goals and requirements, so that they can fully understand the needs they are working to fulfil. Don’t let the PO or a business analyst be the only person talking to users and customers.
Once people have been part of the conversations, documentation will serve as a reminder rather than the “single source of truth”. That means photos from a whiteboard used in a discussion posted on a wiki, is likely to be a lot more useful than a detailed document someone has spent days writing.
3. Learn early by delivering often
To enable us to emerge and evolve our requirements, it is necessary to learn as quickly as possible. That means we can’t just sit and wait for requirements to change; we must actively seek opportunities to change them!
We need to prove early whether the assumptions we’ve made are correct or, maybe even more important, wrong. One way to do this is by delivering small increments often. If we are able roll out each small increment as an A/B test to a subset of the users to prove or disprove its effectiveness, this can be a very powerful method. In other cases, we may have to settle for putting it in front of our stakeholders and get their feedback. It may not always be desirable to deploy a partial feature to live but we shouldn’t allow that to stop us from learning!
4. Don’t act on a whim
Finally, let’s make sure we don’t act on a whim. Emerging requirements don’t mean it’s free for all to throw requirements at the team or to randomly change their mind. Some changes will be worth the effort and cost of implementing them, but in other cases there will be more important things we should be doing.
The challenge is identifying which changes are worthwhile. As always, if we can base our decisions on data, we will increase our chances of getting those decisions right (more about that in a later blog post).
Have you had any challenges with requirements changing (or not changing)? What did you do to solve it? Please share your ideas in the comments below!