Writing Better User Stories
The Importance of Conversation and Shared Understanding
Alistair Cockburn, one of the authors of the Agile Manifesto, famously described a user story as “a promise for a conversation.” As the various Agile methodologies have matured, we have moved further and further away from the heart of what Cockburn and others were conceiving of. Debates rage between proponents of user stories and job stories, frameworks place the sole responsibility for story creation on business side roles like the Scrum Product Owner, and the rest of what is needed to effectively convey what exactly it is that needs to be done has been left by the wayside.
So how do we fix our user stories?
To do so we need to rediscover that original conversational intent of user stories. To paraphrase Jeff Patton, a thought leader in Agile product development, that conversation should be held between the people closest to the problem (users, stakeholders, etc.) and the people responsible for solving the problem (your Scrum team). Collaboration between these groups yields the best solutions because it creates a shared understanding of the problem to be solved and the proposed solution.
Regardless of who is involved in the conversation the goal should be shared understanding. Ideally for any given user story the parties described above are able to participate in the entire refinement process as doing so yields the best possible user story. However, this is typically not practical in reality because of time constraints. Your team can’t write code if the entire team is constantly involved in endless refinement sessions.
To get around this issue while still ensuring that everyone is involved in refining stories, I iterate through multiple refinement conversations adding more participants as the work starts to come into focus.
The process in detail
The first conversation is typically between the Product Owner (PO), the Experience Designer (XD), and me the Solution Owner (SO). The SO role was developed by Slalom to accelerate the maturation of teams, which in consulting are generally new to the client and project, so that they become high performing teams much more quickly than they would otherwise. SOs fill the unique combination of the product owner, scrum master, project manager, and Agile coach roles necessary for each client and project to achieve that acceleration. This session, or series of sessions, is aimed at generating a lo-fi set of wireframes or some other visual representation of what we think needs to be done. Having a visual aid to serve as the basis for future discussion makes it much less likely that the group will reach a false consensus and come away with different ideas as to what we need to build. Keep the visual aid as lo-fi as possible to avoid putting work into polish that may be wasted as the UX/UI changes as the team iterates.
The next conversation adds the Solution Architect (SA), dev lead or whoever can provide a technical assessment of the feasibility of the design and start work on the architecture, and the Quality Engineer (QE). The lo-fi design is presented, and everyone has a chance to ask questions. If the SA or QE share concerns about the design the group works through changes that address the concerns where necessary. Once the SA and QE feel comfortable with the UX/UI the designer is tasked with producing a higher fidelity output.
Once the higher fidelity designs are available that same group (generally PO, SO, SA, QE and design) meets again to draft a work item based on the designs and anything else pertinent to the story that has come up in the conversations thus far. The stories that result from this process rarely follow a single template (like the classic user story template). Instead, they mix and match acceptance criteria, personas or other user information, business context and information around the value we expect this to bring, technical/implementation/testing notes, the design(s) that were created as a part of the process, and anything else that is necessary to represent the shared understanding that has been built through this series of conversations.
Finally, the draft story is brought to the team refinement session where the entire team is present to review the work. The team member best able to effectively communicate the shared understanding represented in the work item presents the work item. Generally this means that the Product Owner or Solution Owner present frontend work, and the Solution Architect presents backend and other strictly technical work. There are cases where this may change and generally there will be a clear choice as to who should present the work based on their familiarity with it and ability to effectively describe what needs to be done. After the work is presented, the team is encouraged to ask questions or raise any concerns they may have. Once the entire team is satisfied the work item can sized/estimated/pointed.
Bringing it all together
This process is intentionally built to be flexible. The conversations you have and the people involved should be shaped to what you expect the work to require. At times that may mean the classic user story template is the right tool for the job. Other times, instead of reviewing a wireframe or prototype the team will be looking at an architectural diagram and the result will be a technically focused story that doesn’t mention the user at all. The timeline and individual meeting time boxes should also be customized to the needs of the team and your stakeholders. I set up recurring weekly sessions that cover the average refinement time needed by the team and then add ad-hoc sessions as necessary.
Stay focused on ensuring the process reflects the unique character of the work under consideration and facilitate the discussions with an eye towards iteration, collaboration, and shared understanding. If you do this the resulting stories your team creates should be of high quality, and easily understood, while minimizing the need for future iteration and rework.
