Want to hear a story? Well, if you work with product development, you’ve undoubtedly come across User Stories before. You may also have learned about their use for representing work items, usually on a Product Backlog with Scrum or with anything agile.
But do you truly grasp their true nature?
In many companies — too many, actually — there’s a chasm between Business and Development. Business is usually on one side, at times located on different floors or even in separate buildings (!), creating extensive specifications. Once ready, these specifications are handed to Development on the other side… Possibly accompanied by pizza and coffee.
Development then splits the tasks between them, gets each one’s part done, and puts it together to hand the resulting work back to Business so they can analyze and approve it… Or not. In this last case, even more documents are created. It all results in very large cycles with very little collaboration.
In such a scenario, it is impossible to be agile. It is impossible to be adaptive. For that, we need much stronger collaboration between Business and Development.
"Business people and developers must work together daily throughout the project."
This is one of the twelve Agile Principles, principle #4. In that sense, Extreme Programming, an important agile methodology for software development, advocates actually having someone from the customer (or potentially from Business) working directly with the developers. The agile framework Scrum relies on the role of a Product Owner for that. Although we advocate that the Product Owner should not be the customer, they hold the responsibility of generating business value by defining hypotheses of what are the next most important things to be created.
One way or the other, either we have someone with a business perspective working with Development, or we have business people in the team, we get Business and Development working together. And that’s how we shorten these cycles.
The first thing about User Stories is that they are based on that idea that we, Business and Development, need to define together what needs to be built. In Scrum, for instance, Product Owner, product developers, and possibly other stakeholders can come together during one or more Product Backlog refinement sessions or in a Sprint Planning event to collaboratively prepare User Stories to be implemented. That’s what we call the “conversation.”
The second thing comes from the term itself: “User Stories”. It’s all about the user! Some would say it states the user’s perspective. What I could say is a story describes something a user can do with the product, something you will allow this user to do by creating this functionality.
Traditionally, the Extreme Programming practitioners who invented User Stories would write them on index cards. Today, sticky notes or digital tools may be more adequate. Still, we refer to the backlog items written as User Stories as “cards.”
As a result of the preparation work that takes place during the “conversation,” the desired behavior of the implemented functionality is defined for each User Story, for each “card” to be implemented next. That’s what we call the “confirmation.” It is usually expressed as acceptance tests — automated if possible, as advocated by Extreme Programming — or as acceptance criteria, which could later be turned into automated tests. The acceptance criteria or tests exist mostly with the purpose of guiding the developers on what they need to create during the implementation work.
Those are the three C’s of User Stories — Card, Conversation, and Confirmation. The “card” provides a brief description of what the user will be able to do, the “conversation” represents the discussions made during collaboration between Business and Development, and the “confirmation” outlines how the functionality will behave once implemented.
The most commonly used template for expressing User Stories establishes WHO/WHAT/WHY and looks something similar to:
“I, [WHO], can/want/should [WHAT] so that I can [WHY].”
"WHAT" is usually an action, what the user will be able to do, that which will be implemented.
"WHO" is the definition of who that user is, which can be represented as a user persona.
"WHY" is the direct value or benefit the user will get from being able to do the "WHAT."
For example, “I, Joseph the teacher, can search books by title so that I can choose to buy them.”
When implementing any User Story, we will only create what is sufficient and necessary in terms of layer, component, or technical parts to support the value to be generated for the user. This means that our product is developed incrementally, as all the parts below the User Story itself will be pulled by it and grow alongside it. This approach enables us to be adaptive and responsive to emerging and changing requirements.
In summary, User Stories can play a vital role in promoting collaboration between Business and Development for defining what will be built while keeping the user at the center, and in supporting the incremental delivery of value, making them a crucial technique for product development.
Comments