User Stories and Story Points: Common Misuses and How to Leverage Them

Recently, Sam and Dan discussed velocity; an important metric to agile teams, and what it looks like when used correctly vs. incorrectly. In keeping with this theme, they’re exploring two other important metrics that are also often misused and misunderstood: story points and user stories.   Story points and user stories are all-too-commonly misused. In this episode, Sam and Dan debunk some of the common misunderstandings, share how both concepts are often misused, personal experiences in their roles as agile coaches, and how to correctly use them.   Key Takeaways What are user stories? How can they be misused? User stories come from extreme programming as one of the practices that were advocated for during its emergence User stories were born out of a need for telling a story about what the users want the system to do (and use that instead of the detailed requirements documentation that nobody actually reads) Kent Beck is attributed to coining the term “user story” User stories have good intentions and work in a particular context but are often misused and come with a multitude of unintended consequences If the user story framework helps you, great — but if it doesn’t, don’t use it (don’t think that you have to use it because it “makes you agile”) The idea of the user story framework is to concisely suggest to developers what a user might want to do with a system (it should also answer: What kind of user? What kind of behavior? And why?) Good vs. bad uses of utilizing user stories: Misuse: If you simply want to do something as a developer, put a task in your backlog; you don’t have to twist it into a user story format Misuse: Writing everything down and believing that the problem has been clearly communicated (Just because it is written down, doesn’t mean there is a shared understanding) Correct use: When user stories are used to have a conversation about what we want the system to do or what the user wants the system to do Misuse: If the user story is short enough, it isn’t necessary to have an abundance of written documentation (If you’re finding yourself needing to attach a lot of written documentation to the requirement, it is most likely too broad of a scope for a user story) Misuse: You don’t need to know all of your stories ahead of time to get the project done Correct use: Understand that in creating user stories and moving through your agile journey, many of them will be wrong and it’s unknowable Correct use: Conversations should be happening more frequently and be broken down into smaller pieces so that everyone has a clearer picture Tips for leveraging user stories effectively: Get in the mind of the user so that you can better come up with some strategies for appealing to their needs or fulfilling their needs Address the acceptance criteria/conditions of satisfaction (i.e. How do I know when I’ve achieved this goal?) Try to make the user story about what the user is trying to achieve (i.e. conditions of satisfaction) Reference User Stories Applied: For Agile Software Development, by Mike Cohn Don’t take user stories too seriously Remember the three Cs: Card (because they used to be written on index cards), Conversation, and Confirmation Good vs. bad uses of story points: Misuse: Story points are often conflated with days (i.e. how long it will take to do something) which, in turn, become used for velocity metrics (which is then often weaponized against the team [listen to episode 135]) Misuse: You shouldn’t be predicting too far out with story points (instead, talk about what you can do in the next couple of sprints and then go from there) Misuse: Similarly to user stories, don’t take story points too seriously (i.e. don’t take them as means of precision beyond having had a conversation around something that is possible to do) Correct use: Story points are simply unitless measures of relative size (in sprint planning you can worry about the finer details and granular approach) Misuse: There is no value in breaking up story points into multiple points, resizing the stories, etc. (It’s supposed to be a close-enough/estimate… it’s not supposed to be precise) Misuse: Software development is unpredictable and filled with unknowns, trying to force specific predictions with story points is counterintuitive Correct use: Breaking things into smaller pieces with user stories is a lot easier to figure out the size of the task Closing Thoughts: Don’t take user stories and story points too seriously Don’t think you know more than you do Cut yourself some slack and cut your team some slack Break things down into smaller and smaller pieces The smaller something is, the more easily it’s understood and the fewer unknowns there are   Mentioned in this Episode: Agile Coaches’ Corner Ep. 135: “Exploring Velocity: What is iI? How Do We Measure It? How Can We Leverage It?” Lean Coffee User Stories Applied: For Agile Software Development, by Mike Cohn Killer Nashville Devil in a Blue Dress: An Easy Rawlins Mystery, by Walter Mosley   Want to Learn More or Get in Touch? Visit the website and catch up with all the episodes on AgileThought.com! Email your thoughts or suggestions to [email protected] or Tweet @AgileThought using #AgileThoughtPodcast!