Why User Stories?

A Placeholder for Conversations

One of the most common questions I get when working with teams and individuals during an agile transition, is “Why User Stories?” That usually leads to more questions, like…

  • What do they mean?
  • What should I write?
  • Who should own them?
  • Who should write them?
  • How do they relate to tasks?
  • And many, many more…

At its simplest form, a user story represents, captures and provides a reminder of not only what has already been discussed but what other conversations need to happen because of what is or is not included in that original user story.

User Story Template

User Story Template

What is a User Story?

In SCRUM and many other Agile processes, we use User Stories, or a variation of then, to define and capture needed work. It is usually presented in the basic format of:

As a (this type of user), I want to (do this action), so that I can (accomplish something that matters to me).

So why do we use this type of structure? This sentence captures many aspects of the work in one sentence before diving into the detail of what it is. It quickly conveys, who the feature is for, what they want to do and why it matters both to the person who will use it and how it fits with the priorities of other work being done on the project. It is a common place to start, not only for what that feature means to the target user but offer a place to dig deeper into the reality of what building it means. It is a foundation for conversations that need to happen during the process of planning, estimation, prioritizing and implementation.

Depending on the needs of the project, you can take time to dive deeply into each these elements with a structure of persona, feature areas and value propositions so there is a common understanding for all of those working on it but it is not always the best use of time. Fleshing out the different user roles you can think by defining them as a persona for greater depth and representation of their needs, motivations, limits, behaviors, goals, allows each team member to put themselves into that person’s virtual shoes and understand their needs. Needs that are often VERY different from the person building the product. It keeps you connected to who you are making it for and the value the work provides to them.

Why User Stories?

Many of us are used to documentation (Product Definition Documents) that details every element of what a feature is, what it does and the requirements behind and in some cases, the person or persons, that the feature is targeted for. The challenge though, is often by the time we see it, the person(s) who wrote it is not around to ask for more information when the work actually starts, so even if you wanted to get more information about what, why, and ensure a deeper understanding of what those tools or features are meant to offer in greater scheme of the project, the opportunity is not available.

A user story breaks down much bigger ideas (sometimes documents) and needs into smaller, iterative elements (guided INVEST) that are identified as the work progresses through the course of the project, allowing product owners, stakeholders, and team members, to recognize and impact ongoing learning cycles that naturally occur as the project evolves over time and adjust to that evolution whether it be in implementation, team expertise or changes in technology. Agile methods and estimation as based on the premise that you know the least about the work before you start the work and the user story itself is just the first snapshot of what is needed, it is not meant to fully define the “how” of its implementation. That part is defined by the individual and team doing the work and all the influencing factors: environment to missing expertise, to time, and so many others you are probably not even aware of yet. Which is why that user story is a placeholder for conversations that MUST come as the discovery, iteration, and learning occur. Accepting that to meet the needs of the story, the team and their solutions for “how” may need refinement along the way from the person who wrote the user story, define and prioritize the need for the work that has been requested.

User Stories and Tasks

One of the biggest “ah ha” moments for the use of a user story is when individuals realize that it is meant to represent the collection of work needed to make that user story element a reality. We are so used to task lists and often user stories are first perceived as “just a task” and not a collection bucket for the related tasks that complete the work it describes. There are times that the user story is the work but in truth, those should be rare occurrences. A tool I often use to decide if the user story is the task or it is a collector for a set of tasks, is to ask the question with the user story, “In order to build/create this feature you have to…” If they answer, “Just that,” it means things got a bit too detailed and broken down (though as mentioned earlier, there are times when that one piece of the user story by itself it is the right way to approach it for a number of reasons – a missing piece from something earlier or a priority you do not want to miss). More often then not, it is a list of stuff, “I need to do setup that, write this, code that and that, test this, add this image from that other story, connect this to that…” a list that is created by the person who will do the work to make that user story a reality.

Who should write tasks is part is one of those discussions that comes up often as part of this process and I believe that if you are not the person doing the work, you should not be writing/defining the tasks or the order they need to be done. That said, during the planning meetings things are often moving around quickly and folks are asking questions about the work, clarifying, questioning, asking for a set of use cases, whatever they feel they need to get it done and in that storm of information, tasks do get written and often incorrectly. So no matter what, the person doing them needs to make sure they do the final edits on that task list. If you are using tracking software, one of things solutions I have used in the past is to send the team a list planned of user stories for the next iteration for preliminary review so that when we have our planning meeting there is a baseline of what is ahead but also so that they have had time to think through the work and find  dependencies or other things that impact how they would approach the story. Many teams are made up of specialists or only having one member on the team at that time with that skill which means dependencies and potential blocking issues are the norm, in these cases, I instead, add a placeholder task to the story when I know that person HAS to be part of the solution that simply says “Review user story and add tasks.” Simple, quick, they can find it in the tool easily, take 5 minutes to look at one or a few of these during the course of the day allowing future meetings move that much faster. Note that it does take a while for that to become a team “working agreement” or habit, but it can save you a LOT of time in the long run. Another side plus, is that during the meeting, if you are reviewing a list that someone has already put together, another team member speaks up and says, “I need to help with that, add a task for me too.”

The Conversation

The Conversation

So About those Conversations…

When you move into an iteration or sprint, the work begins… now you learn about what is REALLY needed as you dig into the work and figure out you did not know enough to ask the right questions… what next? In the user story, the product owner or creator of the story, might have included a list of baseline requirements, details about acceptance criteria for how the feature needs to behave or work with other features, even potentially detailing buttons to include what text to present to the user during the experience, use cases and other clarifying details. I like to include a list of what I call “assumptions” because they define what the work is not, allowing the team to scope down the overall work with what it does not have to do and better estimate what the work being asked for really is. (Example: Assumption – sample data okay.) At the end of the day, if you need more information, you need another conversation.

As a Product Owner and Scrum Master, I often end an iteration planning session with a simple statement, “I am here to continue the conversation. If you find you do not have what you need to move forward, come find me.” It may seem odd to have to remind folks, but when you work with smart people who like to dig in, get focused on solving problems, and what to get it done, that connection matters. Agile is about collaboration and if you are not working with the right people to solve challenges you are facing, you need to re-evaluate not only what you are building but the process used to build it. Having had roles on teams where I often wore many hats, these conversations could be challenging and at times I would preface comments with “As the Product Owner,” so that they knew exactly which hat I was wearing when referring to the topic because it clarified the position and my impact on what was done. As a Product Owner, I was a direct influence on the outcome of the work, and if there were two options for how to solve it, I needed to be part of the decision for the additional information that I might have about the business, budget, new data, etc. Information comes along at many times during the length of a project and user stories need to be continually groomed, updated and refined when it presents itself. Other times as a Scrum Master, I had an opinion about how my team should approach the solution but I was a coach, so while I was there to advise, the decision was theirs to make (and learn from).

In most cases, these conversations are quick, not “real meetings.” More often than not, the need for this quick clarification comes during or after a stand-up when a team member mentions what they are working on and says “Can I have 5 minutes to talk through X before I get started on it?” There are times though that during the evaluation when the work starts, team members discover that the best next step is having a larger meeting with “the right people in the room” – experts, designers, the product owner – to make sure they are all on the same page for what needs to get done and to find the best “how” for moving forward. These days technology has become so complex that we cannot know everything about anything, even if we are the resident expert, accepting that and appreciating the talents of those around you to inform and guide you, to understand the trade-offs and timing needed to best move things forward at a consistent pace and your own consistency about those interactions makes finding solutions around the hardest challenges easier. As you work closely with the team, they begin to understand clearly the priorities and trade-offs you have to make for the good of the product and they evolve into an amazing source for guiding you and your decisions toward the final vision of the product. You have built trust overtime with those who can help you figure it out. Find the best solution for the questions at hand but have those conversations, and, if you are not available, which will happen eventually, ensuring the team knows the goals and priorities looking forward, they can make the best decisions they can in your absence and when you return, at most, a minor course correction is needed to get back on track, and not a potentially “Titanic sinking” level event.

Write the users stories. Encourage everyone in the team to write them. Ensure they add the details necessary to trigger a future conversation about what they are and why they matter – this is the best way for the project to evolve in a natural, iterative way by identifying parts and pieces that were not even thought of when the first stages of work began or even when that first user story was written with a basis on the conversations needed, not a user story that was written months ago. Have those conversations when and where needed to remove impediments, clear up uncertainty and keep your project on track.

The user story is your reminder that conversations need to happen during the iteration and beyond as new work is identified and questions arise.

Leave a Reply

%d bloggers like this: