Are User Stories always the best way to capture agile requirements?

If you are in an agile team and don’t use user stories, you are probably in the minority. But if you do, are you finding that they are always the best way of capturing requirements? I have recently come to question the typical format of a user story and its suitability to all requirements sets. The committed agilists among you (and I count myself as one of you) might, at this point, be starting to splutter and spill your coffee, but please… hear me out. All else being equal, user stories are the best way of capturing and managing requirements that I have come across. But… there are one or two situations in which their use is potentially compromised.

The “As a… I want…So that…” format (or variations of it) has been around for a while now and has become commonplace. But have you ever found it difficult explaining the “so that…” part? Take a regulatory project, for example. All the stories are ” so that we comply with the legislation”. Not especially helpful, is it? But even if all the “So that…” clauses are the same, what are the implications in dropping that part of each user story, leaving just the “As a… I want…”? Probably not a lot to be honest, but does that make it no longer a user story? As long as it is clear how the individual stories contribute towards the goal of compliance, then I don’t see a problem. But is there then a better format for user stories under these circumstances? Or should we be using something else instead?

Let’s look at another aspect. User stories also work best because they deliberately defer the detail of each requirement until the team starts working on it. This is only possible because you have a Product Owner / Business Ambassador around to provide the detail behind the requirement as and when necessary. But what if you don’t? What if your Product Owner isn’t around for more than one day a week and even then you have to collar him between meetings? I know some of you are shouting “Get a different Product Owner”, right? In an ideal world, yes that might be the answer, but his replacement may be equally as busy and may not be as knowledgeable. So, let’s say you’re stuck with the guy you have. Do user stories still work as well? Not really. The limitation is in the deferral of detail concept. As noble an idea as it is, that is not always possible. The less active business involvement you have in the team, the less you can rely on vague or woolly user stories being sufficient to capture requirements. When the rest of the team need to be able to just get on with the coding and testing without the business being around, the requirements need to be more detailed, don’t they? More like little specifications, in fact.
Here are some options:

  • expand the “I want” part of the story to provide more detail,
  • attach supplementary materials (models, mock-ups, annotated screen grabs etc)
  • expand the acceptance criteria into full Specification by Example scenarios
  • Or has anyone come across a format for a teeny tiny specification that still meets the INVEST criteria (although without the Negotiable bit – IVEST)?

    Advertisements

    About aterny

    Agile enthusiast and evangelist, DSDM practitioner, trainer and coach. Specialist in Agile project and programme management, governance and organisational transformation
    This entry was posted in Agile and tagged , , . Bookmark the permalink.

    2 Responses to Are User Stories always the best way to capture agile requirements?

    1. PM Hut says:

      Hi,

      This post summarizes Agile – everyone wants to have his/her own flavor of it and we are ending up with a complete mess instead of some good practices to manage a project.

      I’m not saying that what you’re saying is wrong, but I’m just pointing out the fact that standards are very important for a methodology – that’s why the PMBOK still has the upper hand.

      • aterny says:

        Comparing Agile with PMBOK is like comparing Sport with rugby. Agile is a philosophy and a set of principles, the PMBOK is a project management method.
        Compare PMBOK with, for example DSDM and we have a valid conversation.

    Leave a Reply

    Fill in your details below or click an icon to log in:

    WordPress.com Logo

    You are commenting using your WordPress.com account. Log Out / Change )

    Twitter picture

    You are commenting using your Twitter account. Log Out / Change )

    Facebook photo

    You are commenting using your Facebook account. Log Out / Change )

    Google+ photo

    You are commenting using your Google+ account. Log Out / Change )

    Connecting to %s