A ready story is a user story that is small, independent, actionable, and clear enough that it can reasonably be committed to by someone to complete it. For most teams, our largest stories, Epics, can be collaborated on, defined, and broken down into ready stories using a shared document tool, such as Google Docs or Confluence. The most important aspect early on for this activity is to simply get the ideas out and shared conversationally with the team concerned with this level of the project. Any tool you choose should not impede this. Instead of focusing on the documentation tool, format, or process, the focus at the beginning needs to be on conversations.
What conversations are we having?
We have lots of conversations as a team. Sometimes we are describing a problem and seeking a solution. Sometimes it’s more about improving an already ok situation. Sometimes it’s about a completely new idea trying to find its way into becoming real, and hopefully proving valuable. Whether we are doing something about something, building something for some reason, or simply improving something for the sake of improvement, our efforts at this stage seek alignment with others involved that can help as well as seeking a consistency with who we see ourselves to be and where we see ourselves going.
Whether we know it or not, when we are trying to do things, we are on a mission of sorts having at least some sort of vision of where we are trying to go. Companies eventually, if not right away, try to form these concept officially as part of their understanding of themselves as a business. As such, they are a business on a mission, with a vision of where they are trying to go. These kinds of conversations are useful because Mission and Vision statements can help as guardrails to most conversations about doing new things. Identifying concepts such as Mission and Vision statements is consistent with the general strategies for distilling conversations in to ready stories.
By ready stories, we mean the User Stories that we will get to further along where we are trying to go in our journey for making ideas real. So how do we get there? We first want to distill these early conversations into some type of discreet idea that fits with the other discreet ideas to make up the bigger picture of what we want to do. If we do have a sense of our mission and vision, we can discuss our ideas and try to describe them as initiatives that are consistent with our mission and will help move us toward our vision. Our initiatives, for example, can be something we’ve identified that we want to improve in order to work toward some ideal outcome. Maybe its maturing a new service, or increasing some aspect of a customer base by some percentage. Ideas this big are certainly not actionable on their own. So we need to break them down.
Initiatives, in this sense, can be considered our first type of issue that can then be broken down into Epics, our largest Stories that can be completed.
Who are we having conversations with?
When our role is somewhere between or, if they are the same people, in relation to the stakeholders and the customer, our primary concern is in delivering the right product. Let’s think of the right product as one which can be described as being mutually beneficial to both the customer and stakeholder roles in their relations and experiences with the product. Discovering what will likely be mutually beneficial takes empathy in our conversations with customers and stakeholders alike.
We want to focus not only on what stakeholders and customers want, but also what they might need that isn’t immediately obvious to them. In addition to these conversations, when working with stakeholders on what we might build to create a valuable product, we’ll also want to be discussing the prioritization of what to build first to safely test a way forward and avoid as much risk as possible. The benefit from these discussions should be that the stakeholders are able to fund the most valuable work first, but the goal of these conversations is to create documentation of clear, organized, and prioritized features to bring to the team to develop.
Documentation for collaboration and reference
We need to be documenting our conversations as much as possible for the purposes of better organizing our big ideas, breaking them down further, and being able to reference them later as we share this understanding when they are being considered for development. Starting with meeting notes, we never know what might become important so we want to note just enough to remind us of the conversation, but not so much that the meeting’s conversation loses steam. We want to be identifying new ideas, how they are responses to previous measures or feedback, and how the new ideas identify potential directions for future experiments. Depending on how well the ideas emerge in the conversations, we will create independent documents for some directions and ideas so that we can focus on their viability, perhaps with further focused conversation, research, and exploration. The ideas that emerge into their own, deserving of deeper focus, at this stage are typically, and reasonably, considered as initiatives that the organization is getting serious about committing to.
Either in these focused documents, or in ones that stem from them, we’ll likely start thinking of them as each representing a new product feature, outlining its requirements. At this point, we are safe to consider the idea in focus as reaching the Epic level, in terms of our idea breakdown hierarchy. In our thought organization, at the Epic level, we’ll want to be thinking about how to structure our information so that it may act as the most effective reference for the development team, their conversation, and eventual commitment.
Up until this point, our work could be performed in any document sharing program that works well for multi-author collaboration. We are approaching the point where Epics will be broken down into Stories, which will be tracked, split, and broken down further in the development team’s issue tracking system. So, this is where some collaborative document sharing programs may be better than others if they have any integrations with the issue tracking system. The more integrations there are, the less things will feel like a “handoff” at this point, and we’ll be able to more comfortably continue conversations about our work with feet in both systems.
For example, this can be seen in the ways Confluence integrates with Jira.
