It is always better to spend the least amount of (time, effort, money) to get what you want, right? If I can get a tasty meal for $10 why
would I pay $30 or $200 – for the experience of eating – that isn’t about taste. That is a different thing, isn’t it. We have different priorities for eating – being full, healthy, tasty, being served, fast service, being able to relax, a pleasant experience, being able to brag about my meal/experience. Each of these is a different reason for selecting a dining experience. Each of them is valuable to some people some times, but not all people all the time. The way we choose to spend our money to eat is not that different than the way we choose to spend our money on software capabilities; there are different reasons why we prefer one capability or a means of delivering a capability over others.
These are the principles that I use to guide my story elaboration – and thus my ability to challenge those who would ask me to do more than the minimum…
1) There is a reason that a story is valuable – (the sponsor is willing to pay for it)
In every story there should be a “so that” or “in order to” clause that explains why we are paying to do this work. The so that is usually not quantified, or even quantifiable – but it does provide guidance to our elaboration. Often when discussing a story, other ideas come out. Some of them are alternative ways of delivering the same “so that”, others of them are related means of delivering another “so that”. Maintain the discipline around what is this idea and how does it deliver the “so that” – keeps us from getting complicated, confused, or constipated.
2) A story is not the only idea we have for delivering its value – (we have more than one way to solve or fix or grow)
As we elaborate a story, as alternative means to the same end are discussed, we should write them down as separate stories to be explored… separately. Don’t lose track of your ideas, because we may decide that this idea is not good enough, and it pays to have the backup plan already documented. When we try to keep all the ideas for delivering a “so that” in one story, we often end up getting stuck or talking ourselves in circles as we try to keep our thoughts together.
3) While discussing any story, other ideas are brought to light – (but they are not this story)
Sometimes we realize as we are evaluating this story, that other things can be improved. There are other (perhaps related) so that’s that we could be getting after. Don’t lose track of those ideas, they may be very valuable – but if we keep them inside this story, we may dilute the so that of this story while we incorporate more value. Resist the urge to “add value” to this story – make a new one and decide that that value is important enough to be done.
4) If we can deliver the same (or similar) value more simply that is preferred – (increasing complexity increases long term cost)
Sometimes we see a more direct path to making things better. Sometimes the first path we try ends up adding one value, while reducing other values. Sometimes while we are figuring out how to add something valuable to our product, we realize that we must adjust valuable capabilities that are already working. Just remember that the most direct path, the most independent means of producing value is likely to be the easiest and fastest way.
5) If we think we know what our customer or end users will like we may be surprised – (getting feedback from the simplest idea helps clarify the remaining ideas)
We often believe that we know what our customers want. We convince ourselves that our ideas are good, that they are the best ideas. We become emotionally invested in those ideas. When we do this, we want our ideas to have the best chance of being adopted. So we polish, refine and improve our ideas until they are the best they can be. But then they are expensive – and if our customer doesn’t adopt it, it is waste. Remember your ideas do not actually add value to the product except when they are adopted. So the best way to get your customer to adopt an idea is if he thinks it was his idea. That is why feedback is so important. Release simple, raw ideas, and let the customers feedback be the driver of refinement, improvement and polishing.
6) A bird in the hand – (delivering small value today is better than the promise of more value tomorrow)
Because value is only realized through adoption, the sooner I can release an idea, the sooner it can be adopted, ergo the sooner the idea starts to accrue value. The converse is that the sooner an idea is rejected, the less I have invested when I abandon it. Either way from a cost or a value perspective – delivering sooner is better. That argues always for us releasing incrementally, and providing new valuable capabilities is simply and quickly as possible.
Following these principles will help you keep your stories independent and small. They help you avoid “packing the box” – the practice of defining requirements that nearly ensure delivery failure. They guide you into less waste. Someone <reference> did a study that revealed that something like 80% of the features in most applications account for 20% of the usage. That means that for every story, we have a 1 in 5 chance that we are working on one of the 20% features that account for 80% of the usage. The thing is, we often can’t tell the difference until we observe what the users do. Everything up until that observation is speculation. What these principles are about is making smaller bets.