Last night I finished reading User Stories Applied: For Agile Software Development by Mike Cohn. It was a nice quick read to get my feet wet in the world of applying user stories.
I really prefer working with user stories as opposed to full-blown system requirements specifications. Although a typical SRS is much thicker than a set of user stories, I think more information is actually delivered through user stories because it’s done piece by piece. As you require the information, it’s your responsibility to gather it—which leads to better understanding and more timely discoveries.
Here are some insights from the book that really resonated with my experience.
The Psychology of Story Writing Workshops
“Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she’s comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions.”
This hit close to home. I have to admit that at my first story writing workshop I didn’t say much. It was kind of a foreign concept to me and I worried about getting shot down by the other developers if I mentioned a story idea. I felt like there was a good chance that would occur because the rest of the team seemed to have a similar vision of how the product would look and feel before any discussion had even begun.
I later realized that they did indeed want to hear my story ideas, but it just took some time getting used to the culture of the team. The key insight here is that creating a judgment-free environment isn’t just nice-to-have—it’s essential for getting the best ideas from everyone.
Developers Make Poor User Proxies
“When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users’ minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user.”
This is such an important point. I know as a developer that there are many times where I know how I would like a piece of software to work. Because it would work well for me, I assume it will work well for users. But ultimately that’s not always going to work best for the end user.
The book points out that developers typically lack:
- Marketing backgrounds to understand the relative value of features
- Customer contact that salespeople have
- Domain expertise in the business area
- Understanding of user workflows and pain points
It’s difficult to put yourself in someone else’s shoes and try to think like they would. It’s much easier to just ask, instead of making a design decision, implementing it, and then later having them tell you that’s not what they wanted.
Who Should Write the Stories?
“Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers.”
Wow… I had no idea. Right now we’re writing the user stories ourselves, which according to Cohn is not ideal. This makes sense though—the customer understands the business value and user needs better than we do. Our role should be to facilitate and suggest, not to own the story creation process.
This revelation makes me want to rethink how we approach story writing on our current project.
The Blame Culture Problem
“In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you’re not responsible for something you can’t be blamed for it when it fails, yet there’s usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases.”
This seems to happen more often than not. When someone becomes slightly hostile about prioritization or decision-making, it’s usually because of their own insecurities about being blamed for failures.
Reading this helped me realize I should think about what stakeholders are going through. Who’s grilling them? What pressures are they under? How can I help them be happy with the software while also making them look good to their peers?
Understanding the organizational dynamics behind resistance to user stories is just as important as understanding the technical aspects.
Why User Stories Work Better
The more I work with user stories, the more I appreciate their advantages over traditional requirements:
Conversation over Documentation: Stories are conversation starters, not conversation enders. They force ongoing dialogue between developers and stakeholders.
Just-in-Time Detail: Instead of trying to capture everything upfront (which is impossible), details emerge as you need them.
User-Centered: The format forces you to think about who the user is and what value they’re getting.
Flexible: Stories can be split, combined, or reprioritized as understanding evolves.
Key Takeaways
After reading Cohn’s book and reflecting on my own experience, here’s what I think makes user stories successful:
- Create a safe environment for story creation—no judgment, just capture ideas
- Get real users involved whenever possible—developers make poor user proxies
- Let customers own the stories—our job is to facilitate, not write
- Understand organizational dynamics—resistance often comes from fear of blame
- Embrace the conversation—stories are meant to spark discussion, not end it
User stories aren’t just a different way to write requirements—they’re a different way to think about building software. The focus shifts from documenting what we think users want to having ongoing conversations about what they actually need.