How much time is spent on writing and maintaining user stories on typical software companies? Writing actual documents with descriptions, acceptance criteria, ordered lists of steps? Is it worth it to spend hours maintaining what could be nothing more than a post-it note on a wall?

The process of writing comprehensive user stories has been generally accepted as norm but in reality that’s not the original way of leveraging their power. I will claim that user stories have a lot hidden power that’s being chained tight due to process; let loose, most teams I have worked with would have been far more productive and able to respond to change.

Tell stories, not write them

The original source for user stories stems from Kent Beck’s Extreme Programming methodology. Beck explains this to Jeff Patton, author of User Story Mapping:

If you can tell stories about what the software does and generate interest and vision in the listener’s mind, then why not tell stories before the software does it?

— Kent Beck

If we consider the impact of telling a story instead of writing it, we will realize its significance.

Notice how Beck hints at a user story being about sharing a problem and not a solution. Framing the problem is the one aspect that connects customers to the product. This subtle, yet profound tweak considerably changes the mindset of the team and their product manager.

A group of people such as an entire team is privileged to actively listen to that story. If you were to simply read the story from a document, you would not be able to ask questions, validate your assumptions and propose solutions, at least not immediately.

The amount of time you spend discussing a user story and changing it is significantly increased. Writing a large block of text affects overall performance. More specifically, you would be spending time writing the user story with some detail, send it over to the team, have them read it some time during the day, receive questions, answer them, schedule a call and finally updating the story again. This is the best-case scenario; imagine the worst one. If you contrast this approach with problem-focused, short stories discussed together, the outcomes are remarkably better.

Finally, the insights and creativity you get from active discourse are far more relevant than a written document. It is no secret that while it is important to dedicate a significant time of the day/week to perform deep work, I would argue there must be a time for the team to engage in intentional group thinking. The commitment to think more instead of writing more leads to more plasticity which in turn enables better response to change.

To clarify: I’m not proposing that we stop writing anything anymore. It is clear that remote work now dominates knowledge work settings and written documentation is more important than ever. I propose that teams prioritize thinking collaboratively over writing documents in their routine but not completely dismiss the latter.

Put a size to stories, not estimates

Here’s a fun fact: if you search for “estimate” or “estimation” in the Scrum Guide, it yields zero results. It does include one single mention of size. The difference is big enough to compel any team to transition from estimation to sizing.

Any time someone asks a contractor to rebuild a part of a house, estimations are usually provided, so as to inform the person who hires them to get a feeling of how much it’s gonna cost and how much time the job will take. These estimations are used to compare different contractors and make a decision on who to hire. In the end, you’ll get exactly — or close to it — what you ordered.

Innovation work such as software development is a completely different setting, in the sense that a team does not know what the solution will be most of the time. They might have multiple solutions and they’ll have to choose one, depending on the outcome they’re looking for. Estimating becomes counterproductive because no solution is fixated; rather, it is plastic and is reviewed constantly.

Sizing a user story is much more natural and interesting because it fosters collaboration. If a story is too big, the team attempts to size it into smaller, valuable, and less risky portions. If it’s too small, the team can assimilate it into another small story and treat them as one. Depending on the level of maturity and cohesion of the team, the very definition of size might differ but it usually comes down to either effort or complexity.

That’s all it is: an indicator that promotes collaboration. No date commitments, no deadlines, no estimates for completion. Treating story sizing as such sets a dangerous precedent for the wrong form of control. Contracting a set amount of story points per unit of time is strongly ill-advised and should not be considered in any circumstance.

Sustain customer-centric experimentation

Changing user stories is a normal process. It encourages teams to identify user problems with a degree of precision and offer solutions, while not losing perspective of the product’s vision and strategies. The most important thing to retain from user stories is that they summarily identify user needs and they aim to help us achieve high-level, user-centric goals.

Running experiments is a natural posture to adopt when building complex products. These are sustained by a higher level goal and they verify that a goal is closer to being achieved. Success of those experiments is usually measured through indicators inside the product, with the frequency level that allows those experiments to be considered successful.

You can also measure user engagement towards an idea. For example, if you’re unsure whether to add a feature that delivers some value, you can experiment with some technique such as a prototype, a poll or a lead generation page that will effectively collect the data you need to validate your idea and decide whether to invest more or less in it.

Hypotheses of those experiments must always be customer-centric; you validate user behaviors / outcomes. This should not be confused with business outcomes as they are vastly different in scope than user ones. Also, business outcomes are mainly driven by user satisfaction, which is precisely what you’re aiming to measure.

This level of validation is hard to achieve with closed-off feature roadmaps, where the validation and feedback loops happen at the end, typical of the smashing majority of businesses around the world. The risk of planning something to be used six months from now and not being valuable is absurdly high.

User stories go hand in hand with experiments, in the sense that stories define what the user needs, and experiments attempt to solve, validate or learn from those needs.

The value of talking about what users need is far greater than writing about them. Not only will teams benefit from the time they save, they will also be more open to change, think deeper about problems, gain more perspective by collaborating with each other on the high level goals to achieve, as well as a refined sense of purpose.