The never ending Christmas list

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'

 

This entry was posted in Agile Adoption, Agile Benefits, Agile Coaching, Agile Development, Agile Methodologies, Agile Software, Agile Testing, Distributed Agile, Extreme Programming, Lean Software Development, Scrum Methodology. Bookmark the permalink.

One Response to The never ending Christmas list

  1. Roberto says:

    I agree with this article. But there are exceptions. For example, in ISO26262 regulations for the automotive sector, we must take into consideration scenarios with small probability but which can cause dangerous effects.
    They are, however, agree with the idea of ​​starting with the use scenario rather than by “the system must …”
    Rather than an analysis of the requirements (because safety should always be ensured even in the rare event) it would be better analysis of the features. I find it very interesting approach MoSCoW (Must Should Could Wont).

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>