I very much appreciate getting stories written in “user voice”. You know the ol format of “AS A… I WANT TO… SO THAT…”. At least when it actually communicates a user’s desires rather than being filled in with nonsense like a required field that people don’t see the purpose in (e.g. “AS A user I WANT TO click the login button SO THAT I can login”).

Understanding why I am implementing a feature helps me custom fit the solution to the user’s needs. So if you are given a user story and the user’s desires aren’t clear, then ask! Don’t settle for just doing the things in the acceptance criteria. It is the personal responsibility of every member of the development team to know why a feature is being implemented.

One area I have found this principle to be particularly beneficial is reporting. It is important to know the value of each aspect of the report so that you can compare the value against the cost. In reporting, you will often have to collect data from various sources, even within the same data store, and combine, filter, aggregate, and sort them. Some data points and operations come free with the main set while others come at an additional cost.

Understanding the cost and value of each aspect of a report can aid you in having informed negotiations with the product owner to develop a report that best fits the question(s) the user is trying to answer with it. I’ll often push back on requirements around sorting or searching which tend to be nice-to-haves but can add significant latency to a report.

One important question to ask is “how fresh does the data need to be?” and “why does it need to be that fresh?” This is particularly important at scale when a report might take a few seconds or even minutes to generate. If the user wouldn’t come to substantially different conclusions by looking at the data from an hour or even a day in the past, then I can cache some or all of the data in an easily queryable format for that report.

If the report can be generated in milliseconds rather than minutes then the user can interact more with the data. Making it easier and pleasant for them makes the feature more useful. However, cache comes at its own cost and if they just need a data dump then I’d rather let them grab a snickers and wait a while.

If you aren’t already, start asking question about the user’s intent. Understand what questions they are trying to answer or outcomes they are trying to achieve. Then weigh the value against the cost so you can efficiently build an effective solution!