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.

Join the Discussion

    • Chris

      Steve, the reason why I discourage people from writing only “I need to be able to log in to the system” is that it has the potential to leave out important context. The actual user may not need – or even want to log into a system. They just want to use it. So who does need people to log in? Security? Compliance? Or are we just assuming that we need to log in?
      Capturing the real need and who actually needs it is important, so I don’t think you’ve picked the best example there. The template works far more often than not.
      Having said that, yes, I believe that there are occasionally some stories for which the “so that” is self-evident.

      • Steve Ropa

        Hi Chris, Thanks for the thoughtful reply. I do agree that context is important. I always try to remember 3 “W’s” when I am writing a story: Who, What and Why. These three reminders get to the crux of the matter, and leave us the freedom to stay in the realm of natural language, which is my big beef with templates. So no fair making the template

        Who: ______________________________
        What: ______________________________
        Why: _______________________________


        As far as the login example, not having all of the different permutations listed forces us to have a conversation about the story, which is a Good Thing. Having a template implies that if we fill it out, we have answered all of the questions, and thus don’t need to have the conversation. This was what was wrong with traditional requirements documents, and takes us all just a little further away from valuing Individuals and Interactions over Processes and Tools.

    • Alistair Duguid

      I too have had doubts about the desirability of using the template. I feel that the additional context provided by the template is useful in about 25% of stories, but that the additional real estate taken up by the extra verbiage is detrimental in nearly 100% of cases in that it clutters story cards and story boards.

      Whether you are using Post-It notes or GreenHopper, or anything inbetween, I feel that the understandability of the stories is damaged by the forced inclusion of the templatee verbiage, and certainly, it is harder to distinguish stories when they are laid out either physically or on a screen, when so many of the words on each story card are the exact same. At the very least, I advocate a simple story title as the main heading, with the “as a..” verbiage pushed down to smaller point size.

      Additionally, as you point out, the template format has already become dogma. I have seen teams strive to “correct” stories to the “proper” format by inserting the verbiage when it added no value.

    • Fred Williams

      Hi Steve,

      I hope you’re still monitoring the comments here.

      Have a look at this:


      It’s a video of a lecture I delivered at Agile Prague last year. I’ve refined it since, but this gives you a good idea of the main concepts. I had the same problems with user stories templates as you, so I proposed this instead.


      That’s a better format, in my opinion. I’ve now introduced this at several companies, large and small, and the feedback is positive. Let me know what you think…if you email me, I’ll send you more details.


      Fred Williams

      • Sylvain Hamel

        I do believe you have left out a very important part, if not the most important of all: SO THAT!

        How you are going at it is only relevant in the context of why. If you later need to add a user story to the iteration that was left in the backlog for some time the why becomes very important because the software has often changed so much.

    • Steve Ropa

      Hey guys, great thoughts! I believe that it is helpful to remember the Who,What,Why for a given story. I just fear using a template as it tends to drive us away from thinking about the story, and toward thinking about the template…

    − 3 = 4