It’s commonly accepted nowadays that we use user stories or some variation on them to communicate our “product requirements” to development teams (job stories, jobs to be done, scenarios, etc). And while this is certainly an improvement over some of the bad, old Big Up-Front Requirements (BUFR) methods that were used many moons ago, they’re still not perfect, for a wide variety of reasons. All too often, they assume that certain considerations have already been made, that certain work has already been done — when in fact it often hasn’t. Not every development team has a UX and UI member dedicated to help them achieve a story; not every product can afford to have user-story level architecture decisions being made — and every User Story has to be the result of some amount of planning and forethought, both from a business and a technical perspective. While user stories are a great tool, they’re far from the only tool that we need in our drawer to be effective. Here are some things to consider when you’re relying on User Stories as your primary method of relaying work to be done to your development teams.
Where does your ideation happen?
First and foremost, user stories should be the result of some amount of project planning and strategic thinking; they shouldn’t just be randomly dropped onto a backlog and assigned out willy-nilly. While it’s popular to say that we should only pose problems to our development teams, and leave them free to do what they need in order to solve them in the way that they think is best, we still have to answer to a business that has needs, desires, and deadlines. Often, this requires us as Product Managers to do a very shallow dive into the “how” while maintaining our vision on the what — so that we can provide guidance to our development teams about just how much work we want to budget for a given initiative or project. Not many companies can afford to just hand a list of stories over to their teams and accept that they’ll be done when they’re done — rather, there are often assumptions and constraints that the business applies to these solutions. Whether for “right” or “wrong”, this is the reality of many Product Managers, and we need to ensure that we’re tracking and tracing this work somewhere so that when we do get to the point of having a User Story backlog, we can all refer back to these thoughts, plans, and decisions to ensure that everyone’s on the same page going forward — or to challenge the limits placed due to some new information that we’ve obtained.
Where does your design happen?
Another challenge that many teams have with relying on User Stories as their primary means of defining problems for the development team to solve is that UI and UX design simply isn’t always embedded with the teams. And, since we want our User Stories to be “shovel-ready” when they land on our team backlogs, this means that we run into issues where different teams might wind up taking different UX approaches unless we have some form of centralized vision and guidance on the solution. While I’m wary of UI and UX becoming too far embedded in the “how”, I also see the value in ensuring that there are people who are taking a longitudinal view across the entire product to ensure that the overall user experience is consistent, compelling, and modern. We don’t want engineers to also be designers — far too often that results in a hodgepodge of UX concepts that should be better aligned. And if we want the design done up-front, even if it’s wireframes, storyboards, and direction rather than dictates, we need to make sure that we’re allocating time for this work to happen before a User Story winds up on the backlog of any development team.
Where does your architecture happen?
User Stories are tactical bits of product development that are focused on supporting our customers’ needs and solving their problems. All too often, this fact results in unnecessarily constraining the work being done to an existing software, hardware, or framework architecture that’s already in place, because it “works”. But, in this modern era of stability, scalability, and speed, we can’t always afford to just assume that the way things have been done in the past, and the underpinnings of the platform that we’re working on, can or should remain in place. Unfortunately, in most organizations, User Stories exist on a scale that doesn’t allow us to do major refactoring — sometimes it doesn’t even let us switch the wheels on the bus while it’s still cruising down the highway. And this poses a danger to products that are entering a mature stage of existence — sure, you can continue rolling in revenue based on an old architecture, nothing’s stopping you. But at some point there’s going to be a new player in town with new ideas and modern frameworks that will do everything that you do faster, better, and with greater scale. We owe it to our company, and to our product, to ensure that we’re raising issues of architecture and that we have plans in place to renew and revamp our fundamentals every so often so that we’re less exposed to these up-and-comers who have none of the technical debt or must-keep-going pressure that we do. “Good enough” won’t be in three years, I can almost guarantee it.
