Barry O’Reilly exhorts today’s leaders to “break the cycle of behaviors that were effective in the past but are no longer relevant in the current business climate, and now limit or may even stand in the way of your success.” After more than 15 years of writing, “refining,” “grooming,” estimating, documenting and coaching people about user stories, I believe it’s time to unlearn them.
I realize that’s a big statement and likely to be not a little controversial. But in a vast and sad irony, user stories have become the heavyweight documentation and process that they were meant to replace. Indeed, as Kent Beck shared, “Somebody came up to me and said, ‘We want to do software development but we just can’t stand all this ceremony and this Agile stuff. We just want to write some programs.’ Tears came into my eyes… How can it be that we’re right back where we were twenty years ago?”
Not unlike points estimation, user stories have taken on a life that I’m sure the manifesto signers never intended, and, as Beck alludes, was precisely what they were hoping to escape. As Martin Fowler has remarked, “a lot of what is being pushed is being pushed in a way that, as I said, goes really against a lot of our precepts.” My problem isn’t with user stories per se; it’s with how we use — push — them in practice. If we are dealing with an Agile Industrial Complex, then user stories are the weapons that convince us that we can’t be safe without them, that we simply need more of, and that themselves become the gauge of success rather than the things they’re meant to help us achieve.
But it’s amazing what happens when you strip away the accrued behaviors and get back to the heart of agile: I’ve been working on a side project building a web app with a friend, and I’ve been able to experience how refreshing and dynamic software creation can be when we free ourselves from the methodological fetters that we inherit and reinforce, of which stories are one (and one that I’ve been guilty of perpetuating).
Curiously, user stories are nowhere to be found in the agile manifesto or its principles:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Let’s focus on a few of the principles in particular and how I see the current practice of user stories as actually inhibiting agility and transgressing the spirit of the principles.
Working software is the primary measure of progress.
Quick: What metrics does your software delivery team and/or organization track? I’m guessing that nine out of 10 of you will say some kind of output-related metric whose origins are based in user stories: story points, velocity or even count of stories.
In my side-project experience, my teammate (who, by the way, is remote and in another continent) and I never even countenanced the idea that any of those story-based concerns would matter, so much that they don’t exist for us. We care chiefly about building something that people will use and enjoy using.
How might we focus on working software? To start, replace the daily standup — a Mos Eisley spaceport of anti-patterns rooted in stories* — with micro-demos (e.g., every day or every-other day). Then constantly validate that you’re building the right thing by letting people use it.
If you don’t think this is a problem for teams today, consider: How much time (meetings), effort and conversation do you and your team spend in the business of stories as compared to the business of validating whether you’re solving business problems and realizing outcomes?
Simplicity–the art of maximizing the amount of work not done–is essential.
Speaking of time, how much time in dehumanizing meetings, Jira jockeying and estimation meetings have you endured under the guise of agile? Many organizations and teams have unnecessarily complicated their delivery systems with over-engineered story-tracking tools, incessant refinement meetings and elaborate processes. Try working without stories, and you might find you have a lot fewer meetings — and more time to do value-added work.
Business people and developers must work together daily throughout the project.
User stories, far from being the linking point between business and IT, have instead become another way to pass the buck onto IT without any business responsibility or involvement, creating a collective wedge of miniature contracts. IT needs involvement from the business? We’ll give you a product owner, who will in turn spoon-feed you requirements, er, stories. I think this crossing the business-IT divide is really the hardest part of agile delivery, but one that will be exposed when you remove stories. It will be a forcing function to align business and IT.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I, like many agile coaches, have for years taught the “Three Cs” of user stories: Card, Confirmation, Conversation. The card is a promise for a conversation! The only problem is that in practice, the card replaces the conversation. When stories take on a life of their own (e.g., in ticket systems), they become an impersonal interface not unlike the tomes of spec docs that we used once upon a time.
Conversation in real life is spontaneous, organic and natural. It flows from trustful relationship with and proximity (even if remote) to other humans. It’s possible to do this in delivery teams, but it’s inhibited when conversations are reduced to scheduled sessions and transactional instructions. And these “conversations” betray a mindset that says that the product owner knows best, and that developers need to seek their permission, rather than product people being comfortable stating the problem and what outcomes we need and letting smart people creatively solve problems. (John Doerr captures the essence of this in his awesome expression missionaries not mercenaries, which Marty Cagan elaborates on.)
The first value of the manifesto is about Individuals and Interactions over Processes and Tools. User stories and all of their trappings have become the epitome of process and tools. Let’s free ourselves to interact as people.
If not Stories, then what?
It’s actually easier than you might expect, though when you think about it, it shouldn’t surprise you. Software makers (and I use that term broadly to mean programmers, designers, quality advocated — anyone who enjoys creating software) are usually creative problem solvers. Give them the problem, and they’ll not only discover the solution, they’ll enjoy the experience of freedom, knowing the goal they’re aiming for. And they’ll create even better solutions that what we might’ve originally conceived (and codified on a user story).
Rather than define my point of view in the negative as only something you should not do (I’m not starting the #NoStories hashtag), I’ll propose what I think teams should do. All you need are some enabling constraints:
- clear product vision and goals
- trust and psychological safety
- low level of work in progress
- tight feedback loops
In the case of my side project, all three of those were in place:
- Vision: Vision isn’t a one-time slide in a deck. My teammate and I talked when we started about what we wanted to accomplish and have reiterated and progressively elaborated on that vision. By living the product vision each day, you really can live without user stories, but it does take clarity from the product person and enrollment from the team.
- Trust and safety: My friend (actually he was nearly a stranger when we started, but we have become friends) and I had an initial conversation to understand each other’s personal goals and interests. Ever since, we’ve been in regular contact and have reinforced the mutual trust and psychological safety — no punishments, no incentive plans, no minimum “average velocity” — nothing other than helping each other realize our goals.
- Low level of work in progress: Without my permission, my teammate sets his plan of attack for the day, knowing that whatever he works on, he’ll focus on building someone that I can see. This is part of the creative freedom that developers need: Without the central planning of a product owner that is reduced to too-discrete pieces that often don’t sequentially make sense from a development standpoint, my friend is able to follow his creative instincts and engage in flow.
- Feedback loops: Since my teammate is constantly building and releasing — and because he knows that I’m not expecting perfection on the first try — we casually and frequently exchange feedback, not only validating that we’re on the right track but also allowing what has been built to generate new ideas and learn from “happy accidents.” What we are creating is better than any user stories could’ve guided us toward.
I concede that it’s possible for teams to succeed with user stories (I’ve been on some of those teams), in which case this call to unlearn isn’t for you. But taking a clear-eyed view of the state of software delivery today, I’m concluding that, in general, user stories are inhibiting agility rather than enabling it.
I propose breaking out of the single-loop learning cycle that attempts to improve how we do user stories and, rather, taking a double-loop learning approach to questioning whether we should use stories in the first place. Free people to do their best work through humanizing patterns like high-bandwidth conversation, psychological safety and flow. This is how creative software building works. I’m becoming convinced that people would enjoy their work more if we let them work in this way, and that ultimately organizations will be able to create the kinds of software products that are even better than they envision and realize the outcomes that they’re hoping to achieve in the first place.
* Story-based anti-patterns:
- This story isn’t estimated.
- There’s no way that’s a five.
- Let’s schedule a meeting to refine those stories.
- These acceptance criteria are in the wrong format.
- The PO is out today; you’ll have to wait.
- Can you update your cards, please?
- Tell me what to type in the description.
- Can you make a story for that before I do it?
- Is this a bug or a feature?
- This story won’t fit in the sprint.
- I’m not sure we can commit to that.
- I think we need a spike before we do that.
- That’s a task, not a story.
- We can’t work on that until it’s been refined.
- Can you please add the details?
- What am I going to accomplish today? Story #654 and maybe start on Story #679.
- I can’t estimate that if I don’t know the solution.