The strange case of technical user stories

Warning

“Continuous attention to technical excellence and good design enhances agility.”

Manifesto for Agile Software Development

Note: An original Spanish version of this post is on

http://www.gazafatonarioit.com/2020/08/el-extrano-caso-de-las-historias-de.html

When Kent Beck came up with the idea of user stories as part of the eXtreme Programming planning game, he did not imagine the impact that idea would have on software development and, by extrapolation, on product development, several years later; it was like a «butterfly effect«. In fact, at first he only described them as something where clients define the project scope «with user stories, which are like use cases.» You can find more about this in “The history of user stories” (in Spanish).

But one of the practices that have lasted to this day is that of wanting to express everything as a user story. In practice, this is possible. Since user stories can be represented in infinite ways. In the book User Stories: a pragmatic view, which we wrote with Jorge Abad, who also shared some of his ideas for this article, we spoke precisely about some of the modes of representation of user stories, including the User Stories Conversation Canvas , a canvas to hold and record conversations about these items in the product backlog.

However, there are some things that are definitely not user stories. The «given name«, that «user» in “user story” is there for a very important reason that not even Kent Beck himself imagined at the beginning. He spoke of “stories”, simply stories: these are seen, perceived, understood, described from the point of view of who is going to use them once they are implemented or who is going to consume them once they are part of the products or services that are developed using this technique.

So, when it comes to software, those so-called technical stories are not a good idea. Who is the user of «I want to integrate Google AI to translate the text»? Or «I want to optimize the database to speed up queries»? But it is possible to know who is the user of «I want to translate a text to my native language so that I understand it better» and of «I want to consult the client’s information» with the condition that the result of the query is presented in less than two seconds.

It is a fact, representing something in the form of user story when it is not about users-people of the system is a mistake. There are better ways to document or record these other types of “internal” activities of a system. One of them is precisely putting them in their place as tasks that the team must perform to finally achieve something of value for the user-person through one or more user stories. Let’s think of user stories as «person stories.» Perhaps this will help us understand the difference.

One of the ways to know if something is a «user-person story» or not is when having conversations with business representatives, for example a Product Owner, these conversations flow naturally and the source of information is almost always the business representative. But if she starts asking for technical terms or expressions that emerge in the dialogue and the development team has to give intricate explanations that are not of her domain, then perhaps we have crossed the plane of the value or benefit of the story for users to one of the technical team domain.

«We have to do a left outer join followed by a deduplication» is something we lose users with. “We refactor the code daily and then integrate it with the rest of the team using Bamboo or Jenkins”, while “we automate the test scenarios using behavior-driven development” and “we consume the web service of [INSERT YOUR FAVORITE WS PROVIDER HERE] to know the value of the dollar minute by minute”, are classic conversations that will leave a Product Owner or any other person in the business areas on edge.

These expressions will sound very strange to users. Moreover, when many of those words mean something totally different in the everyday life for ordinary people:

A «left outer join«? – What is he playing at?

«Behavior Driven Development«? – Are you talking about how your behavior in the company has you to the test?

«And what about my query for customer data?» They ask with eyes wide open and with that discouraged expression that only means they are not getting what they want and that even leads them to think the team members have not understood everything that users need. Usually it is a combination of both. The matter gets more serious if someone on the team tries to explain in more detail what all that technical rigmarole* means or tries to justify the estimated development times. At this point it is clearly evident that the presence of a facilitator, coach, Scrum Master or similar is required to abort the conversation and take it another way.

Finally, let’s not understand user-person stories or person stories as those that only address the «front-end» or user experience, of the person. No. Every user story has “vertical” components that go from the way a person communicates with the system, to how the data exchanged by that person with the system or the environment is stored and processed: database, services, business logic, presentation, and so on.

More on how to conduct conversations with user stories in our highly effective user story series:

http://www.gazafatonarioit.com/p/la-serie-historias-de-usuario-efectivas.html

In Spanish.

And still much more in the book User stories: a pragmatic view (English edition).

Call to action

Let us explicitly separate user stories, those of value for the business, users or clients, from the team’s tasks and from the «internal» components of the system (product) with which that value or benefit is obtained. As agents of change, let’s make sure that team members develop skills and abilities in the business domain, helping them and Product Owners and stakeholders to improve interactions between each other through continuous conversation, hopefully face to face (In 2020 let’s turn the camera on!), and ensure that not everything has to be a user story, at least not represented in the same way.

Conclusion

If in the conversation about a user story it is the Product Owner who ends up questioning the team for clarification and not the other way around, perhaps the dialogue is not really about the user story.

Epilogue

*I intentionally used the term «rigmarole«, perhaps less known, to leave the feeling in the environment of what an end user perceives or feels when we confuse him/her with technicalities typical of software development.