MBA042: Stop Using User Stories – Interview with Jim Benson

In this episode, author, speaker, and Kanban pioneer Jim Benson advises us to ditch User Stories and shows us what to do instead. Jim’s recommendation: use the scientific method. Jim Benson CEO of Modus Cooperandi Jim Benson is an internationally recognized speaker and author. He is a pioneer in applying Lean and Kanban to knowledge work, and his books include Personal Kanban and Beyond Agile. Jim is CEO of the collaborative management consultancy Modus Cooperandi and founding partner of Modus Institute. X http://traffic.libsyn.com/masteringbusinessanalysis/MBA_042__Stop_Using_User_Stories_-_I.mp3  After listening to this episode, you'll understand: Why Jim recommends against the use of User Stories The problem with User Stories How to use the scientific method for better results The impact of using a hypothesis instead of a user story  Show Notes In the last few episodes, we’ve discussed how you can be effective using User Stories. Now, thought leader Jim Benson suggests that we should stop using User Stories in favor of an approach better aligned to the scientific method. The Problem with User Stories Jim’s main issue with User Stories is that they’ve moved away from their original intention and become functional requirements in a pretty wrapper. Developers read the User Story (functional requirement) and build it. This assumes that the who, what, and why of the User Story is correct and it will properly address the business goal. We started using User Stories because we lacked empathy towards our customers. However, we still took our own assumptions that we used to put in the detailed design document and put it in the wrapper of a User Story. Use a Hypothesis In reality, everything we’re doing is an assumption or a hypothesis. When we present ideas as a hypothesis, we’re saying three things: I think this is true, but I’m not sure This is the hypothesized solution for the hypothesized problem I’m giving you a set of unit tests upfront A well-crafted hypothesis will encapsulate everything that agile is supposed to do in a more honest way. The original thought behind User Stories is that the team could write them. As we’ve moved away from that original intent, the Product Owner often writes the story with their assumptions, pushing them on to the team. Using a hypothesis allows us to have better conversations about our assumptions and goals. Getting Started To get started using a hypothesis instead of a User Story, we must first understand the organization’s goals for the next three months. This is what the organization wants to accomplish in the next three months, which Jim calls “strategic intents”. Get everyone in the organization together to discuss the strategic intents so that everyone is aware of the goals. Everyone can then share their ideas as to how to support those strategic intents. Ideas are then gathered into big bets and small bets. Big bets are similar to projects, but Jim finds that if you call them bets, people make them smaller (up to one month). All of the ideas and strategic intents are based on hypotheses. Because most organizations don’t do this, you can start by decomposing your User Stories by challenging your assumptions about who the customer really is, what you’re trying to achieve, and how you would test that. Then take that information and create a hypothesis. Hypothesis Design A hypothesis might be stated as: We believe that if we do <what the action is>, we will get <result>, and we will test it by <metrics, criteria, and other tests>. You should also think about and articulate who your customer is. The hypothesis has initial acceptance criteria and tests to understand when the code is complete and working properly. It also has acceptance criteria and metrics based on after the solution is implemented and people interact with it to understand how (if at all) the solution impacts the strategic intents. This allows organizations to rapidly learn and adapt. A hypothesis still follows the three “Cs” of a User Story; Card, Conversation, and Confirmation. The hypothesis should be short (fits on a card), it needs to be discussed to understand and challenge assumptions (conversation), and it has acceptance criteria (confirmation). A team can use spikes to experiment and learn what will work. Jim’s approach to using a hypothesis drives collaboration, adaptability, and creates a learning organization. Z Your Homework Take a few User Stories (especially those that the team is doubtful about) and rewrite them as hypotheses. Treat it like a guess that you can prove or disprove and learn something. What are your thoughts? Have you used any variations on User Stories? Please share your experience and comments in the section below. Links mentioned in this episode: Jim’s Website Modus Cooperandi Jim Benson’s books on Amazon Personal Kanban website Thank you for listening to the program To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes. Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week. The post MBA042: Stop Using User Stories – Interview with Jim Benson appeared first on Mastering Business Analysis.