Why I Don’t Like the User Story Templates

July 16, 2013 Steve Ropa

Ok, so you’ve all heard about The Story Template.  In Mike Cohn’s excellent book User Stories Applied he identifies a format that will help teams learn how to better create stories. I want to point out at the beginning that I really admire Mike.  He has and remains a true leader in the Agile movement, and Scrum in particular.  You can basically count on the fact that advice from Mike is Good Advice. I highly recommend reading all three of his books. The template itself has many good qualities. It reminds us to think about the Who What and Why of a story.  Many folks feel very comfortable understanding what they are looking for by filling in the template.  So in that sense, as templates go it is a good one.  Agile development calls for moving outside of the normal realm of software requirements, and the template feels like a way to ease the transition.  And yet, there is something that really bothers me about The Template.

Maybe we should start with the fact that it is The Template.  I have visited shops that are doing Scrum, or at least they believe they are.  When I chat with them for a while I discover that their sprints are all of varying lengths, they don’t try to make their stories small enough to fit in a sprint, and they really do try to make sure to assign all of the work to the right “resources” in advance.  So not exactly my ideal vision of an Agile team.  But where they excel is making sure every story is expressed in the format As a ____ I can____So That____.  No matter what the story is, they find a way to shoe horn it into that template.  And this is where things start to fall apart.  The need to fit the story into the template becomes more important than the content of the actual story.  So if I have a story that says “I need to be able to log in to the system”, why do I need to say “As a User, I can log in to the system, so that I can…well, I’m not sure yet, that is a later story.”  In honor of US Independence day last week, some things really are self evident.

The main thing that really bothers me about The Template is the fact that it is a Template.  When I look at the Agile Manifesto, which I try to do often, I see the tension created in the value of Individuals and Interactions over Processes and Tools.  Couple this with Responding to Change over Following a Plan, and you see where the template idea falls down.  Agile software development in its many forms is about freeing people up to talk to each other rather than forcing them to fill out forms.  The Template has become a formalized gate.  My understanding of stories when I first learned about them was that they were to bring natural language back to the conversation around what the software is intended to do.  How are we to move away from formal “shall lists” and requirements documents if we are just replacing  them with Story Templates?  Meet the new boss….

Which leads me to my final concern around The Template.  The most common argument I hear in support of that template is that it helps teams transition from formalized requirements, thus easing their transition to Agile software development in general. I respectfully disagree.  Rather than making it easier to transition it delays, and sometimes removes, the need to learn a new way of expressing software requirements.   As teams are first learning how  to do User Stories, they are vulnerable.  They are doing something totally different and have to learn a New Way.  Sometimes, the only way to get over that learning curve is to just knuckle down and do it.  From a Satir change model perspective, I see the template as a way to lessen the effect of the resistance and chaos stages of change.  This sounds laudable, but there is a lot of good stuff that comes from working through those stages, rather than trying to avoid them.  Learning how to write good user stories is hard, and important.  Giving yourself a false sense of security that you are there because you have been able to express each requirement in the form of a template just delays the process.

 

Previous Article
Making Release Retrospectives Strategic and Effective: Part 5
Making Release Retrospectives Strategic and Effective: Part 5

In Part 1 of this multi-part blog series, I presented the case for tying release retrospectives with strate...

Next Article
Follow-Up DevOps Q&A
Follow-Up DevOps Q&A

  After presenting on a recent webinar by CollabNet called “50% Cycle Time Reduction –  Delivery Pipeline S...