It’s funny how sometimes little methods, when applied religiously, can help you develop better products that just make your job easier.
One of those well known methods is the “The rules of 5 whys”, where you try to dig to the root cause of a problem by continually asking ‘why’ at least 5 times until you reach an answer.
Similarly, I’ve been using, an ‘if / what if’ system to make sure that we catch all scenarios when formalising feature development.
Show me how to use it!
Writing a good feature card is hard. It requires time, long-term thinking and a good understanding of what we want to acheive.
This is why, while you are discussing features with the team and project owner, you need as many ‘if’s’ as possible (they will probably become your feature after that).
Let’s take the example of an online shop: you’re trying to formalise what will happen when a user presses the “Add to basket” button.
One person will probably start with
If a user presses the plus icon for the first time, it will create a new item line in the basket with a quantity of 1.
If the user presses again, it will add 1 to the relevant item line quantity.
If the show basket bar is not yet visible, it will make it visible to the user.
If a product is added to the basket, it will refresh the basket preview totals and line items.
By starting with ‘if’, you can quickly nail down what the feature’s common grounds are going to be.
Okay, so now we will probably be able to start writing our feature cards and get the work done.
But, ‘what if’?
Unfortunately, those high level specifications can lead to multiple edge cases later on and some might cause issues.
In order to have a better idea of those, we ask the team to come up with ‘what if’ questions around the specifications.
A ‘what if’ question body is very simple.
- Starts with “What if”
- Followed by an action that could cause problems on the current implementation
- Ends with a question mark
Let’s have a look:
What if the product is out of stock between the page load and the click?
What if the seller stopped trading?
What if they press the button 100 times?
What if they press the button by mistake?
Right, now we have something to discuss. The team might decide to not tackle some of these issues straightaway, but at least there will be some recall of those for later reference.
It’s also important not to delegate the ‘what if’ to only one person, but to ask every member of the team to come up with their own ‘what if’s’. This way, you are proactively seeking for edge cases, proactively looking for trouble and to have a plan for the eventuality.
Incorporating those ‘what if’ questions during our scope and iteration planning sessions allows us to build more resilient products more quickly. I don’t know if this has a more formalised name in other teams, but here, we call them the ‘what if’s’ and we love them.
Picture “Any question”
