Who invented user stories

A common way to formulate stories is the "As a … I want … So that …" form. The "As a" clause refers to who wants the story, "I want" describes what the functionality is, "so that" describes why they want this functionality. The "so that" part provides important context to understand to help get from what the customer think they want to providing what they actually need.

Mike Cohn wrote what is now the standard book on writing user stories. To understand the roots of user stories in XP consider the white book , or the tasteful green book.

Thoughtworks Insights Careers Products. This means a user story also represents a piece of work that should be realized by developers. When implementing a user story the developers extend a system so that it is possible that the user can use the system like it is described in the story.

The verification that a piece of work is done is quire easy when using stories. Someone just has to try whether it is possible to through the system like described in the story.

But as Alistair Cockburn describes, the simplicity of user stories can lead to problems when starting the technical realization. And once again a problem is intended to be solved through communication:. This is a quote from a popular introduction into extreme programming - the methodology actually invented user stories. Valuable also brings misunderstanding sometimes, specially when we break stories as all broken stories share the same value.

Nonetheless, many times, dogmatically I found myself trying to add silly reasons just to fit the template. I now prefer to say that all stories should have something visible that allows the Product Owner to be involved in the development i. Nowadays, I prefer to say they should be small.

We want stories that we understand therefore can be estimated , that fit well in iterations and for which feedback can be provided soon. We may end up with stories that are too big and therefore we need to break them. To slice stories, you just need to understand thoroughly the iterative and incremental process. There are many tips on the web.

Notice how sometimes we break stories to iterate we build something knowing that we will need time to go over it again, as in the case of the first 2 tips and some others to increment as in the last tip. The Agile process is a mixture of both the iterative and the incremental approach. Also notice what I just mentioned about the value of these stories.

It is the same for all broken stories. In Scrum, the obvious answer is the Product Owner as is the person that knows the users and can describe the value expected better. In these cases, someone from the team must help. As a scrum master or tech lead in my teams, I like to do these things. If there are no volunteers, the team may make it a shared responsibility. In the latter cases, make sure the Product Owner understands what is written, how stories are broken and what is included in each card.

And we want to do it using the least amount of energy , so it should be in just one place, easily accessible and that allows us to edit it and prioritize it rapidly. There are tools that I use to record stories with the whole team which I really like because they are really easy to get started with, they are visual, they are tactile and they encourage the collaboration amongst all members.

When the team participates in recording these stories, they will remember them better. Jeff Patton says this documentation becomes vacation photos which people that have the context that were there at the moment of taking can understand as it evokes memories. The first one is obviously the User Story Map. I love this tool as it lets me easily record the most important steps of a story in a very visual way as we can visualize the order of the steps. It lets you swipe horizontally your product fastly, leaving the deeper discussions for later and it lets you prioritize, decide which are the most important steps, the ones that should be built first.

This activity structures the conversation and lets you visually record stories with their examples, rules and questions. Using different colors for these components allows the team to visualize some smells. A final tip. Introspect and get better at writing stories.

Are you using the best tools? Are you easily finding what you record? Are you duplicating information? Are there better ways of doing these things? There's a couple of definitions that could be useful at the moment of using stories to develop. As it applies to all stories, it doesn't make sense to include it in all of them. However, it does make sense to explicit this criteria to make sure everyone on the team understands the same. With some teams, I facilitated an activity to write the criteria and leave it visible in our open space and lately with the pandemics, in our Miro board.

This information radiator is useful at the moment of accepting the first few stories.