Prioritising stakeholder emotions
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”?!
This is exactly the kind of example that really worries me about software dev in general, but especially in situations where not enough significance is put on not just a user’s needs, but wants as well. What lessons can we take away from this, and do you have opinions on the best way to convince the manager and dev team that this is more than just a “nice to have?”
I call into question the judgement of the business representatives who were executing the release planning.
I know it’s hard when you have limited poker chips / coins / beans in your hand and you know those big old “must-do” items are screaming to have “Release 1” written on them.
But, failing to fulfill that requirement early could mean the difference between success or failure of the entire corporation.
To paraphrase the sponsor, “It’s easy to make mistakes when putting loads of naughts on a number”. Those zeroes are orders of magnitude. Orders of magnitude precision in a financial transaction are substantially more than just “nice to have”.
If that 1-storypoint feature was added immediately after the story to implement the capture of the data in the first place, it could save the company (say as Dr. Evil) thousands, millions, or even billions of screw-up money.
$143,524,500,100.00 being transferred to an entity in an external jurisdiction is a mighty whallop when it was meant to be just $1,435,245,001.00
Plus, as you point out, the sponsor (person paying bills) is quite happy that the little, but actually quite significant, feature was added as part of that wacky “responsive, adaptive” software development process.