Skip to main content
Enterprise Agile Planning icon with arrows

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 Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us