Skip to main content
Enterprise Agile Planning Image

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Dec 05, 2013 — Enterprise Agile Planning expert

The Never Ending Christmas List

Enterprise Agile Planning

It’s that time of year when Christmas lists make the rounds of family and friends. This annual rite of passage can usually be summed up as “I want, I want, I want”. Unfortunately in software development, most of our business users do not wait until the holiday season to give us their shopping list; we get their “wants” year ‘round. Think of these requirements lists as the Christmas list that keeps on giving…teams heartburn.

Need Want Like Keys Showing Craving And Desire

Simply calling them “requirements lists” already puts teams at a disadvantage. The word requirement implies that something is needed. The real question should be, are they?

I think if we applied the Pareto principle to “requirements”, we can stop the dreaded bloated project scope. How do you ask? Simple, how many “requirements” does the business offer that are reasonable every day scenarios and how many are obscure exception cases? I bet if you dig into your average 400 page “requirement” document deep enough you will find the majority of the “must have” requirements cover obscure scenarios that happen 1- 3 times a YEAR. While I understand it is important to know what to do if a meteor hits the building, while it is snowing and the coffee pot has stopped working, do we really need to invest in months of development time to account for that?

While that seems like an outlandish example, companies are “requiring” that of their systems every day. Rare, exception paths that occur on such an infrequent basis that only employees who have been around 5 years have even heard of them bloat our systems and delay putting meaningful, useful code into production.

Think about it. What if we only coded the 20% of requirements that meet 80% of the needs, then simply worked with the business to handle those rare exceptions? For starters we would avoid teams crying, “the scope of this project exploded”! Management could stop beating teams up for failing to “control” scope. But most important, the business would get core functionality sooner (and cheaper)!

This isn’t a fantasy world. No one has to ask “If only there was a way…”. We HAVE the way; they are called user stories. While it may be a huge culture change to think of projects in terms of user interactions with a system resulting in value, vs. a nauseating list of “the system shall…” statements, this is the key to avoiding waste. When you elicit and document requirements for user interactions vs an endless universe of possibilities we build smaller, maintainable, scalable systems that the users can actually use.

So, next month when you move away from the Christmas list to that other holiday tradition, the New Years Resolution, please (PLEASE) make leveraging user stories vs. “requirement” lists part of your 2014 goals.sign announcing 'New Year's Resolutions'

More from the Blog

View more
May 31, 2021

Agile change management processes are key to delivering software faster

Enterprise Agile Planning
With its emphasis on delivery value faster, agile product management s ...
Read More
May 03, 2021

Bringing the agile planning approach to your whole business

Enterprise Agile Planning
The events of the last 12 months have demonstrated that the only sure ...
Read More
Apr 08, 2021

Making IT services more agile

Enterprise Agile Planning
The agile revolution completely transformed how we create digital prod ...
Read More
Feb 14, 2021

Reflecting on the 20th anniversary of the Agile Manifesto

Enterprise Agile Planning
Over the past 20 years, it’s been amazing to watch an idea from ...
Read More
Contact Us