Sign up to save your podcasts
Or
Share Lightning Cast: Requirements Rot
Share to email
Share to Facebook
Share to X
Share to email
Share to Facebook
Share to X
Or
Lightning Cast: Requirements Rot
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?”
How to Avoid Requirements Rot
Save 15% with you register for the 2019 Building Business Capabilities Conference by using code MBABBC when you register.
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.
The post Lightning Cast: Requirements Rot appeared first on Mastering Business Analysis.
View all episodes
By Dave Saboe, CBAP, PMP, CSM | Certified Business Analysis Professional | Agile Coach
4.7
8282 ratings
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?”
How to Avoid Requirements Rot
Save 15% with you register for the 2019 Building Business Capabilities Conference by using code MBABBC when you register.
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.
The post Lightning Cast: Requirements Rot appeared first on Mastering Business Analysis.
More shows like Mastering Business Analysis
View all
Freakonomics Radio
32,246 Listeners
The Ben Shapiro Show
153,989 Listeners
The Economics of Everyday Things
1,643 Listeners
Business Analysis Simplified
0 Listeners