Mike Lyons argues that not every task in agile development needs a formal user story. Using anecdotes, he explains that simple bug fixes or minor UI changes (e.g., adding a dropdown value) often only need a one-line note or quick team agreement, and emphasizes prioritizing shared understanding and people over rigid processes and documentation.
Foreign. You might be wondering, should everything be a user story? The answer is no, certainly not. I remember early in my career as a Scrum Master, I joined a team that had already been sprinting for a number of sprints and they were discussing a bug that someone had reported in the system and I said, okay, great, let's write a user story for that. And I remember the lead developer looking at me and saying, I'm not going to write all that crap. I just was like taken aback. We're not going to write a user story. Not everything needs a user story. So consider that bug fix for an example. Often fixing an issue doesn't change the user experience. I mean, besides fixing it, it's broken. But I wouldn't spend time writing a user story for that type of work. A simple one liner might be all we need as a team to fix that problem and move on to the next problem. Or what about adding a pick list value to a drop down menu? No need to write a user story. Like as a system user, I want to see this new value in the drop down menu so I can select it. Kind of a waste of time to say all that. Look, the point is to get to shared understanding, not to have well crafted user stories. Don't get hung up on processes and tools over individuals and interactions. It's the other way around.
