Poor user stories cost money

A user story from an actual client engagement, a story that meant well but completely misses the mark. Also a good example of a requirements-gathering process that’s gone wrong and needed some help.

Can you see what I’m referring to here?
If not, read on and I will explain…

When was the last time you heard of someone wanting to willingly upload compliance documents to a web portal?

I strongly suspected that the principal consultant had not written this story, nor was consulted during requirement-gathering process.

Probably more accurately the real user story here is more like:

𝘈𝘴 𝘢 𝘗𝘳𝘪𝘯𝘤𝘪𝘱𝘢𝘭 𝘊𝘰𝘯𝘴𝘶𝘭𝘵𝘢𝘯𝘵
𝘐 𝘥𝘰𝘯’𝘵 𝘸𝘢𝘯𝘵 𝘵𝘰 𝘶𝘱𝘭𝘰𝘢𝘥 𝘢𝘯𝘺 𝘥𝘰𝘤𝘶𝘮𝘦𝘯𝘵𝘴
𝘚𝘰 𝘐 𝘤𝘢𝘯 𝘴𝘱𝘦𝘯𝘥 𝘮𝘰𝘳𝘦 𝘰𝘧 𝘮𝘺 𝘵𝘪𝘮𝘦 𝘰𝘯 𝘣𝘪𝘭𝘭𝘢𝘣𝘭𝘦 𝘢𝘤𝘵𝘪𝘷𝘪𝘵𝘪𝘦𝘴

Scratching beneath the surface, does the original user story have any merit, and if so, who is the real user and what do they actually want?

Upon some further analysis, the user story actually represents a compliance requirement originating from the finance department, and should probably look something more like:

𝘈𝘴 𝘢 𝘍𝘪𝘯𝘢𝘯𝘤𝘦 𝘋𝘪𝘳𝘦𝘤𝘵𝘰𝘳
𝘐 𝘸𝘢𝘯𝘵 𝘢𝘭𝘭 𝘗𝘳𝘪𝘯𝘤𝘪𝘱𝘢𝘭 𝘊𝘰𝘯𝘴𝘶𝘭𝘵𝘢𝘯𝘵𝘴 𝘵𝘰 𝘩𝘢𝘷𝘦 𝘷𝘢𝘭𝘪𝘥 𝘪𝘯𝘴𝘶𝘳𝘢𝘯𝘤𝘦 𝘤𝘦𝘳𝘵𝘪𝘧𝘪𝘤𝘢𝘵𝘦𝘴
𝘚𝘰 𝘵𝘩𝘢𝘵 𝘐’𝘮 𝘧𝘪𝘯𝘢𝘯𝘤𝘪𝘢𝘭𝘭𝘺 𝘱𝘳𝘰𝘵𝘦𝘤𝘵𝘦𝘥 𝘢𝘨𝘢𝘪𝘯𝘴𝘵 𝘭𝘦𝘨𝘢𝘭 𝘤𝘭𝘢𝘪𝘮𝘴

This is a much better statement of need. It is also solution agnostic.

Now various solutions can be considered, of which many exist, and some likely to be far superior to uploading pdfs to a web portal and then having to manage their lifecycle (eg. storage, access control, retention etc).

It also means that when the time comes to draft the acceptance criteria and accept the delivered story, the right user can be consulted ie. the finance director rather than the principal consultant.

Getting the right details in the right user stories is the difference between software that works, and software that doesn’t. It’s the business’ bottom line that pays.

If you are unhappy with your development team, they may need more detailed guidance.

Clear and effective software requirements can help with this.