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.
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)!
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.