This is not a User Story, or is it? Thoughts about telling and managing stories

Introduction

I still remember how mad David Hussman got when I told him, in his Product Discovery course at Buenos Aires, that after finishing the PD, I started refining what I'd learned into user stories, storing them in a Backlog. I understood at that moment the discomfort many agilists felt by the way user stories had unfolded since the XP fellas coined them.

The original idea consisted of users ‘narrating’ stories of how they imagined a given functionality (stories get their name from how they are supposed to be used, says Patton, and provides a great explanation of them). Stories are the ones that are told. If we recognize the importance of communication, we surely agree that there isn’t a medium as effective as talking. In other words, there’s nothing better than users telling the dev team those stories. This way, we can empathize with them, ask questions. Plus body language enters into action.

All this being said, we do need a way to remember those stories, those small increments of functionality we decompose the product into to work iteratively and incrementally. And we need to store them in a way that enables everyone on the team to understand them the same way.

How should we call the stored stories? User stories (as they represent stories as the painting of René Magritte represents a pipe), backlog items, story cards (not to confuse them)? For historical reasons, I will keep calling them user stories (This is what we, devs, always say when we procrastinate a refactor). Even more important than the preceding question: what is the most efficient way to write and manage these stories?

How to ‘write’ good user stories

Whenever they ask me how to write good user stories, I always answer that each team should find their best way, the way that enables to store them with the minimal effort ensuring shared understanding. The goal is that everyone on the team understands the same about the scope of each user story, investing the minimum amount of energy and time.

There is a very well known format (popularized by Mike Cohn) which ensures there’s always a user doing something that provides some value. Writing the stories from the perspective of our end users ensures the result is something visible/testable, and it also forces us to use the user’s lingo (which in turn forces us to understand their domain, something of utmost importance to model it, right?). We also want to understand (and perhaps write down) why we need this functionality, its value. Let me tell you a couple of comments regarding this part. Here’s the first one: it’s useful to talk about the value of large stories (Patton convinced me it’s better to call them large stories rather than epics) but not that much for small ones, the ones that result from breaking a large one. I used to force myself to do that, but I don’t anymore. The second: Even if the value is there written down (sometimes it happens), talk with the users again, try to understand the problem again. Sometimes you realize that you can solve most of those problems with much less effort.

Of course, you are not obliged to use this format. Use whatever that suits you. Images, photos or anything that let you remember the stories better! The goal is to remember the story in the best way possible.

How much of design we put in a story?

And who does it? A keynote by Mary Poppendieck introduced this question in my head a long time ago, and it keeps coming over and over again. Stories should be mainly about the "what", but the "how" sneaks in when we eventually draw diagrams and screens or even outline algorithms. I’ve seen many stories which provided the whole solution, written by the Product Owner (a non technical person). This is not a good idea. Business people understand better the problem to be solved. However, the details of how to solve it are best known by technical people. Design should be made by the whole team. The wisdom of the crowds will allow you to get a better design, combining business, technical and usability expertise.

How much do you ‘need’ to write?

I’ve been observing, throughout the years, that the amount of information you need to write is inversely proportional to the maturity of the team. I’ve been part of very mature teams where we collaborated and communicated very effectively and we only needed to record the most important decisions. Afterwards, we talked and talked, in the product discovery and while grooming and developing the stories. And I’ve also been in teams where, no matter how much detail we put into the stories, it was never enough. In fact, in these teams we forced ourselves to write things we didn’t even understand (as if writing them would enlighten us).

How big are our stories?

Remember we try to work in small increments of functionality to be able to get feedback as soon as possible and incorporate it into the product. If we are going to work this way, stories need to be small. We should be able to build them within a few days. How long can we wait to get feedback? Not much.
If devs judge a story is too big, we need to break it. There are many tips out there to help you break a story, like by logical groups, or doing the happy path and then manage the exceptional flows, or separate the functionality from the design/usability. I believe, however, that if you truly understand the iterative and incremental nature of stories, you’d be able to figure out how to break them yourselves.

Storing the cards in the backlog

I also told David that I was storing the user stories I wrote in a Backlog. That was the moment he got furious, telling me the backlog is the biggest cause of dev teams forgetting about end users and eventually, the product they are building. Nevertheless, personally I still find that the backlog is a very useful tool. Let me tell you why:

• It allows me to store these cards with just the information we have at that moment, starting from just titles (ideas) until they become refined stories which are ready to be started.
• It allows me to prioritize stories, indicating the set that represents the MVP and, within that set, the order that we agreed to build on.
• The digital tools allow me to search for a particular story, keep working on them, drag them to reprioritize them, or remove them very easily.

In conclusion, the Backlog is a lightweight tool used throughout the project to reflect the current understanding of the team. It’s the place where we all go to store decisions and check what we've talked about. It’s true that we lost track of the big picture, but we still have the story map to look at. You should use all the tools you've got available, but remembering to use each of them for the task they're more useful.

Discovering stories

Developing a software product is a learning process from the 1st day of the Product Discovery until you release it to production. But what is the process we follow to learn? How do we discover all the stories that will guide us in this process? Let me tell you my own experience.

First, I start figuring out most of the functionality needed, without going into detail. Doing a user story mapping is a great tool for this. Once we’ve done this and before going into detail, we need to prioritize, understand what the most important stories are and determine the order in which to build them. After prioritizing, we can start going deeper into each story, polishing the details and agreeing collectively the scope of each of them. Doing this enables us to work more efficiently. Deepening the understanding of each story happens gradually, usually throughout all the construction of the product. The heuristic that I use is making sure we always have stories ready to be developed, without going too far to refine things we aren’t sure we will build.

Who's responsible for writing all that has been learned in the backlog? The Scrum guide says: the PO (who is in charge of writing, communicating and, eventually, the return of investment of the project. Too much, right?). I prefer to say it is a joint team effort as everything else. It’s good though, that when there’s a few people working on the backlog, the PO is aware of everything it's happening. If you want to include the whole team in the writing, there’s a nice tool called example mapping that helps facilitate a writing session. I tried it a couple of times and it worked very well.  

Conclusion

Never stop talking! There’s nothing as effective as users that understand the business domain telling us stories. We can empathize with them and understand the reasons behind each functionality. We can ask questions. We will end up having a better understanding.

We also need a way to store these stories enabling the whole team to remember and work efficiently. And even when we keep calling them just "stories", we should be aware the difference. Finally, the team should inspect and improve the way these stories are stored and managed.

This post is dedicated to the memory of David Hussman - We became good friends while working together. When he got sick, he asked us to organize a course in Buenos Aires because he wanted to meet us personally. We (at 10Pines) will always remember him with affection!