One very important thing that I have learnt from my consulting experience (dealing directly with Clients for building solutions) and in my experience of building exterprise products is:
When you are given a set of requirements, always understand the requirements in terms of what problem of the Customer (an actual client or the product owner) is this requirement trying to solve, instead of just treating the requirement as a feature or an enhancement request.
This may sound very simple, but it has far reaching implications in building great products/solutions. With a good understanding of the inner workings of the product or the architecture or technology or just out-of-the-box thinking, sometimes certain extremely simple alternative solutions might just do the trick with very little or almost no work/re-rework required..!
This was reinforced by one of the examples given by Mary Poppendieck in the Lean Management principles presentation I attended recently:
In the Military/Army, the communication given to the soldiers consists of just 2 things:
- End State
- Command Intent
So, the “Stories” or “Requirements” should specify the “what” and not the “how”.
