Requirements decay over time. Here’s how to prevent Requirements Rot.
Show Notes
Has your organization experienced requirements rot?
A common term in software development is code rot.
Code rot is a slow degradation of the performance of a software application that will eventually make it unusable. While the software doesn’t physically decay, this ever-diminishing performance is a result of not being updated to adapt to the changing environment.
Like code rot, requirements decay over time until they’re unusable.
When we talk about gathering requirements, imagine gathering ripe berries along a path. Those small, valuable pieces of fruit are perfect when we pick them and are best when they’re consumed soon after they’re picked. That’s when they’re the freshest.
If we don’t eat those berries soon after they’re picked, they’ll continue to ripen, then soften, and start to decay until you can no longer eat them. Requirements are the same way.
In a typical waterfall project, we’ll spend several weeks or months eliciting, analyzing, and documenting requirements. After that, the team will likely spend several more months writing tech specs, coding, and testing. When the project is put into production 6-12 months later, the business environment and customer needs may have changed.
You’ve served rotten requirements.
Even in Agile
People often make the same mistake using an Agile approach. They create a backlog and then code and test in small chunks, get feedback, and adapt. That sounds like a good way to prevent requirements rot.
The problems occur when people do “sort of” Agile. This Wagile or WaterScrumFall approach leads to waste and requirements rot when we dive too deep into detailed, ready User Stories too soon.
Do you try to decompose an entire project or epic all up front? Is your product backlog made up of only User Stories that are ready or near ready? Does your team wait for a detailed design before they begin development?
If so, you’ll likely experience requirements rot.
By breaking down a project all up front, we’re wasting effort. As we create something and get feedback, it’s likely that our requirements, User Stories, and approach may change. Many of the User Stories you created will need to change or will no longer be valid.
In addition, the delays waiting for a detailed design makes it difficult to quickly adapt to changing customer needs. We’re delaying getting something in the hands of our customers, lengthening the feedback loops, and slowing our responsiveness to changing market conditions.
Avoid Requirements Rot
Going back to the analogy of picking ripe berries, if you wanted to prevent them from rotting you’d pick only enough berries that you would eat within a few days. As you go back later to pick more berries, you’ll find more berries have grown and ripened and you can pick those.
You can do the same with your requirements. Understand the high level view of your project or epic, perhaps from a workflow or customer experience perspective and using a story map.
Once you understand the high level, you can determine which small slices or journeys to prioritize and go into just enough detail on those. Build something, get feedback, and adapt.
Continue this process of doing just enough analysis just in time based on prioritized slices until you have achieved enough value from the project or initiative and decide to move on to something else.
Remember that lower priority requirements likely have diminishing returns. It may cost more to fulfil a requirement that the value it will bring. Try to maximize the amount of work you don’t do looking critically at the value of some of the slices or requirements.
The real question is “What are you NOT going to do today?”
Thank you for listening to the program
To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes and other podcatchers.
Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.
