I was recently involved in a prioritisation exercise. The application included a UI that presented large numbers to users in financial institutions. The business owner (sadly there was never any question of acutally talking to end users) had complained about how easy it is to make mistakes when adding loads of noughts to a sum – and pondered that it would be great if when the user tabs away from the field that long number is entered, that comma seperators should appear:
i.e. he types 1435245001.00 and on tabbing away the number appears as 1,435,245,001.00.
Cool! It’s captured as a requirement and we move on.
When we go through our prioritisation, it is considered to be a “nice to have”. With a bulging requirements list and estimates squeezing the list, this requirement is initially an early one to go. After all, what business value does it add? But this is where the planning process must be iterative.
The effort to implement this requirement is nominal. Whilst the “business value” is considered nominal, the value to the stakeholder who requested it is emotionally signficant.
When we showcase the story that demonstrates the ability to work complex financial algorithms based upon the number the user enters, the stakeholder will nod his head and say “great”. It does what he expects. But how good will he feel when he sees the commas appearing? Little cost to implement, zero identifiable business benefit, but significant stakeholder emotional benefit.
As a project, when the key stakeholder leaves the showcase, how would we prefer him to feel? “yep, that’s what I want?” or “Gee those guys are good”?!