In my role as a consulting product manager at VMware Tanzu Labs, building products side-by-side with clients, I’ve noticed a trend: More and more, software leaders are seeing the value of including product managers and UX designers on their “non-traditional” projects. While these roles are most commonly associated with front-end, user-facing software applications, the principles we employ aren’t restricted to what you see on your screen; they can also be used to build better, more useful technology that’s used behind the scenes.
But while the guiding principles of our crafts are a boon to all kinds of projects, when those projects are behind-the-scenes software products, the tools we are accustomed to using are not always a perfect fit. One area I see teams struggle with is user stories. Specifically, how does one write user stories when a product doesn’t have users?
Our products will benefit some human, somewhere, eventually. Otherwise, no one would pay us to build them. And user stories, the industry standard method of capturing agile requirements, are meant to represent small slices of user value: real features that can be delivered to a real user that make their lives a little bit better. But when we’re working on a back-end project, whether it’s an API, a replatforming effort, or a data model, we’re often so far removed from our user that a single value-producing story could take months to deliver. This defeats the purpose of small, incremental stories.
Does that mean we should give up on user stories for these projects? In my opinion, no. The counsel I offer my clients is that we can still write valuable stories—we just have to reframe our idea of user value. And that means redefining our idea of a user.
I’m going to outline three different approaches that I’ve seen work under different circumstances—three different ideas of who the “user” is that could be receiving “value” from our story. But the important thing is that you take an approach that is helpful for your team. As a product manager, I ask myself the following questions about our story cadence:
-
Am I able to provide feedback on each of these stories? Can I catch misunderstandings and bugs early?
-
Can I prioritize these meaningfully? Can I advise that we do story A before story B because of the value it will provide?
-
Do I have insight into what the team is working on and why they might have gotten stuck?
If you ask yourself those questions and the answers are “yes,” then you are writing user stories that are serving you well, regardless of which technique you choose.
Developer as user
AS Dana the developer
I WANT the memberData API to return the member’s first name
SO THAT I can make my app seem more friendly and personalized.
In a technique often used on API projects, your “user” is the developer who is going to integrate with your service. This user is a real person who wants your tool to exist because it helps them get some data or features for their software, and who wants it to be easy to use so that they can build quickly and without frustration. On the other hand, they’re not the end user of your data, so you might lack context about the ultimate user value of what you are building.
This approach is helpful when
-
You are doing user interviews with engineers and responding to their feedback
-
You are responding to real feature requests from engineers, who can explain to you why they want certain changes in your tool
This approach isn’t helpful when
-
You are not regularly responding to feedback and requests from engineers, and the “as a developer” line just becomes a stand-in for a meaningful persona
Team as user
AS the data science team
WE WANT to see what our outputs look like if we switch from median to average values
SO THAT we can decide if that data will be more helpful to our users.
Sometimes you prioritize a story in the backlog not because of the direct value it will provide to a user, but because it’s helpful to the team in ways that can result in user value later. If a story is being delivered to provide some sort of value to the team—such as helping you make a decision, or making your code more maintainable—just say so, and instead of clouding the issue by trying to force it into a user-facing feature, be honest about your goals. This is my preferred approach for data science projects, where the team is running experiments to decide how to alter our algorithms.
This approach is helpful when
-
You’ve been noticing a lack of alignment around what your stories are trying to accomplish
-
Half or more of your backlog is made up of team learnings (otherwise, just write them as “chores”/technical tasks)
This approach is not helpful when
-
The team isn’t getting any specific benefit other than getting through one more piece of work
-
You only have a few backlog items of this type—in that case, just add them as chores or spikes
Machine as user
AS Rhonda the Repository
I WANT the clientID included with every request
SO THAT I know which records I should return to the processing engine.
One colorful approach my colleagues at Tanzu Labs and I have experimented with over the years is use of the “machina persona.” In this case, your user is a persona like on any other project—a fictional character with wants, needs, limitations, maybe a bit of personality thrown in—but instead of representing a human, your persona represents a piece of software to which you are connecting. My teams have really enjoyed this approach for replatforming projects, as the metaphor of interconnected pieces of software acting as a team of users working together helps us to discuss what we are building and why. It is especially helpful for bringing people without a technical background into the discussion without them getting lost in jargon.
This approach is helpful when
-
Your code is interacting with various pre-existing systems
-
You need to communicate details of a complex product with stakeholders and team members who don’t have a technical background
This approach is not helpful when
-
You have real humans to talk to who are deriving value from the individual stories you are writing—so if you have the option to frame your value in terms of humans instead of machines, do so!
Remember that user stories are a communication tool. They communicate to the engineers what needs to be done, why, and in what order. They also communicate back to the product manager who wrote them, helping them understand the status of the features and whether the work was done as desired. Whatever approach you take to writing your stories, focus on that communication over following a template. To empower a balanced team, these ideas need to be communicated, no matter who—or what—our user is.
Read more about writing user stories for technical projects in this guide in the Tanzu Developer Center.
