Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.
Remember a few things when you are tempted to get all of the requirements up front:
- Requirements WILL change. In courses I teach the average percentage of requirements which change is 50%.
- Requirements WILL be dropped. We almost always think we can get more done than is possible (or even desirable in many cases). It seems the average percentage of dropped requirements is 25%.
- New requirements WILL come up during development. This too seems to average about 25%.
When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front. Get the requirements good enough to start moving forward. Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt. Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago. This isn’t up to the developers themselves, but the product owners and others who maintain the backlog. Build GREAT products by adapting to changing conditions. EMBRACE change as a good thing, not as an impediment.
Until next time I’m Making Agile A Reality® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.
Related posts:
- Are you agile – the Nokia test I’ve been helping lots of clients start new agile initiatives recently. This...
- Agile antipattern: Taking on large stories Earlier this week I posted a blog entry “Agile antipattern: Burndown charts...
- Agile Antipattern: Everything is priority 1 I was just working on some Powerpoint slides for our Agile Product Management...
RSS feed
{ 3 comments… read them below or add one }
reminds me of Lean priciple of “identifing and eliminating waste”. Waiting for specifications to be ready upfront is an important source of waste.
That is absolutely correct Oana. I created a blog post back in February about eliminating waste. I didn’t mention this particular waste, but several others. I am a STRONG believer in the power of the lean principles in guiding agile practices. Almost all of my courses start with those principles!
- Bob -
Well I tell you what. I wish I’d read this post fifteen months ago when we were just starting out with Scrum. We got the whole concept wrong, and ended up having thrashing arguments with the P.O. about the requirements being changed, wrong, and added.
It was a long and drawn-out battle for me to convince everyone that requirements are not the ‘starting block’ of the sprint, they’re the finish line. (or somesuch)