Defining The User

In Agile, we are often told that everything we do should add value to the user. When you’re building something large and complex like an eCommerce or FinTech product, some work just isn’t user-facing, and it feels very forced and unhelpful to word the story in the “As a user I want to ___ so that ___” format.

We’re also told that stories should be as small as possible. But sometimes it takes several stories to get things working end to end to the point that users will gain some benefit from it, even if it is customer-facing. It’s also easier to do this in a published, working system you’re mostly adding small features to, but harder when you’re working towards your MVP, or early releases after that.

One solution to these seeming contradictions is to widen your definition of “user” to include the development community. Now, stories that make the system more testable, more flexible, more inspectable, more reusable, are all providing user to the user in a meaningful way. Adding functionality to lower systems, taking care of technical debt, adding logging, are all adding value to the user.

This also makes it easier to break up tech/lower level stories. Here’s an example of adding logging infrastructure to your system over multiple stories:

  • “As a developer, I want to have a base logging system so that all parts of the system can record events and issues conveniently and consistently”
  • “As a developer, I want to use the logging system in the user login / profile module so that I can diagnose user login and info issues” (followed by separate stories adding logging to other modules, so the work can me finely monitored and spread across the team(s)
  • “As an SRE, I want log destination to be configurable to files or stdout so that they can be fed into a central repository to feed dashboards, and not take up local storage”
  • “As an SRE, I want all PII/PCI in logging output to be either redacted or encrypted so that our system will be compliant to the law and exposure of those log files does not increase risk to anyone”

Not everyone is going to agree with doing things this way. For instance, here’s a post from Industrial Logic saying you’re not being honest if you’re calling the development community users or customers. They propose having a story that adds value to the customer, and having tasks under it for the technical work. But… then you end up with one large story. If you want to call my proposal the lesser of two evils, then so be it.

Steve Denning also disagrees with the concept of internal customers. And I definitely see his point. Justifying work by saying “WE need it” can definitely be used as an excuse to bloat the system. But if the work you’re doing doesn’t move you forward on the product roadmap, however you describe the work, you’ve already lost. Doing work to add value to internal customers doesn’t actually create that problem.

I maintain that if you are doing valuable work like this that adds to the availability of the system, makes implementing future features easier and quicker, making the system easier to understand for new members of the development community, or decreasing MTTR, you are adding value to the real external end users, who not only want the system do to stuff, they want it to be reliable and available.

There is reason to be cautious here. Using this logic can be a gateway to doing work which is in fact not providing value to the customer, even indirectly, or adding features nobody asked for. Make sure that the “…so that…” part of your story describes the benefit of implementing this story, and the acceptance criteria define how you know when you’re done, so the work doesn’t turn into Never Ending Story. It’s easier to let work with less visibility grow unnoticed.

Care should be take to describe even highly technical stories in a way that describes what you’re trying to accomplish to less technical people, who may need to weigh in on its merits. Dylan Beattie has a humorous blog post about this.

Maybe this part doesn’t need to be said, but.. this internal work still needs to be tested, and those tests still need to be included in regression test suites so you’ll know if they break.

Share

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.