As a business analyst when you ask the customer what he wants in his custom built application his response is always either “I’m not too sure, but I have a general idea” or “I want everything”. Both are vague and generic answers and don’t leave much for you to base your project plan on. What do you do? you go ahead and scare him a little by saying: “Will you please be more specific, because if you request any changes down the road they will be charged”. Now the customer tries to think of every little detail that he can and jots it down on sheets of paper, so much so that he starts thinking of features that ‘may be good to have’ or even ‘may come in handy in future’ and that’s when things start to get messy both for you and the customer.
Here’s a figure showing you how most applications built, have features so abundant that most of them are either rarely used or never used.
So here’s what ends up happening at the end of the day.
1) Along with 20% feature that would actually drive value, you also plan for 80% features that would rarely be used.
2) You account for those 80% features in the proposal and your budget increases 4 folds.
3) Your time lines extend unnecessarily and your QA plan becomes more and more complicated and extended.
4) Your application becomes more bulky and chunky.
All this because we want to be absolutely certain that we nail all the requirements day one. And I can’t stress enough on the one fact that nobody denies or can deny… requirements from a client ALWAYS CHANGE. I have never once seen a case where at the end of the project the customer went “that’s exactly what I wanted, you read my mind”.
A value-driven agile approach on the other hand switches the whole mindset. It assumes from the start that whatever requirements exist up front are not fixed and that they will change. The agile mindset also assumes that you have to deliver by a certain date (just like in any non-agile approach). But this approach fixes the time and resources and leaves the requirements undetermined. To us, this approach more closely resembles the reality of creating software. Now the whole notion of value-driven makes perfect sense. When you have a fixed amount of time in which you aren’t sure whether you can deliver all the requirements (because they will change and hence the time needed to finish them will change), the natural reaction is to prioritize the requirements and finish first those that add the most value to the customer.
So now the questions that you ask the customer are not restricted to just ‘what’ they want but also ‘why’ they want them, and from the list of ‘Whats and Whys’ you prioritize which requirements a client cannot live without and which ones can wait slightly more than others. This brings us to the concept of what we call a product backlog populated by user stories.
I’ll be elaborating on both backlogs and user stories but much later in the series of blog posts that I have planned. Right now I’m talking about concepts one at a time so that you’re able to swallow the ‘red pill’ more easily than most people.
The whole gist of my article is to make you understand the very nature of software development. It is an empirical process and not a defined process. Next time I’ll try and elaborate on this very notion with examples and case studies.
Till then, bon appétit.
Acknowledgment: Some of the references in this article have been taken from Dr. Sidky’s famous book ”Becoming Agile in an imperfect world”. I thank him for sharing his work with me.
