Friday, January 29, 2010

Do I Need User Stories?

How do you create a worthwhile specification of the requirements for a system?

As an Agile Scrum practitioner I’m supposed to answer this by pointing to user stories, but as others have found before me, these are a slippery beastie to define. Cat Schwamm takes a stab at a definition, but finds Scott Bellware telling her she is following Scrum too blindly and should go change what she’s doing.

Scott’s point of view is interesting, but like a lot of his comments he is coming at the problem from the frame of his lean methodology, which is not fully explained and therefore extremely hard to argue with/understand. This is not Scott’s fault, he is after all busy consulting not writing Agile methodologies, but it does make his commentary a tad alarming when one first reads it.

The classic format of a user story is:

As a [user] I need/want [feature] so that [benefit].

Or as Cat puts it:

As a [role] I need [feature] so that [business value].

Cat points out that this is fairly barebones, and leaves lots of scope for you to choose the wrong level of granularity for your user story. She points out that her team also follows the INVEST acronym and use the concept of minimum marketable feature (MMF) as defined by James Shore.

INVEST = Independent, Negotiable, Valuable, Estimable, Small, Testable

MMF = “Smallest possible set of functionality that, by itself, has value in the marketplace”

This is obviously working for her team, but I suspect they benefit from having a single Business Analyst who works everything through for them and ensures some consistency across user stories. This is actually very Agile, as the manifesto points out we value “individuals and interactions over processes and tools”. However, we still need some processes/tools for those individuals.

Scott Bellware’s suggestion was to change the format to:

As a [role] I want to [goal] so that [motivation].

He wants us to avoid mentioning the software altogether and have the user story simply capture what the users actually do (or will do once they have a system to help them). He then divorces the user story from work items altogether, and simply relegates them to the role of being information about the goals of the system. This may work for him, but it then begs the question of how he defines what the work item is all about, which is where we started talking about the need for user stories …

I have been reading a great book called Designing for Interaction by Dan Saffer that gave me another viewpoint on this issue. One of the things I learnt from this book was that user-centred design (UCD) is not the best way to design interactions, it is simply one of the possible ways you could design them and its relevance depends upon the goals of the thing you are designing.

Dan Saffer lists 4 different approaches to interaction design:

  1. User-Centred Design
  2. Activity-Centred Design (aka Use-Centred Design ???)
  3. Systems Design (aka Service Design???)
  4. Genius Design (aka Rapid Expert Design???)

Cat’s user stories actually sounded like activity-centred design, and Scott sounds like he is more interested in user-centred design. Quite possibly they are both right in the contexts they are working in. Neither one may be better than the other (Scott at this point would probably call BS on me, he has previously talked about the need for user stories to communicate expectation).

Coming back to my own issues with user stories, I need to ask what sort of design approach am I taking, otherwise I will find my user stories being all over the place. Is the user story meant to encapsulate the MMF in a single story, or is it supposed to be used to specify all ways of looking at the functionality.

As an example, when looking at the search function for administrators of an organisation I have specified:

  • As an admin I want to be able to search for a member by their Member Id so that I can find a specific member quickly.
  • As an admin I want to be able to search for one or more members by their Member Type so that I can target an action against all members of a specific type.
  • As an admin I want to be able to search for one or more members by a wildcard search of first and last names so that I can find a member just by knowing their name.
  • As an admin I want to be able to search for one or more members by region or industry so that I can find members from specific industries or regions.
  • As an admin I want to be able to search for one or more members by a wildcard search of job title so that I can find members with specific job titles.
  • As an admin I want to be able to search for one or more members by member status for my organisation so that I can target an action against all members of a specific member status.
  • As an admin I want to be able to search for one or more members by activation status so that I can target an action against all members of a specific activation status.
  • As an admin I want to be able to conduct a search against multiple facets of a member at once (e.g. by member status, industry, member type and job title) so that I can get very specific search results.
  • As the system I want to give admins a common page which allows them to search for members for all sorts of reasons and then target actions against the members found.
  • As the system I want to ensure that admins can only ever see their organisation’s own members in search results.

You can see the format slipping towards the end of that list, with the “so that [benefit]” element disappearing. There is also no regard to the INVEST principles, particularly the independent one. If I adopted another (MMF?) approach I might reduce all of that to:

  • As an admin I need to be able to find the members I’m interested in from my organisation so that I can work with those members’ details.

Scott’s format might leave me with:

  • As an admin I want to work with my members so that I can help them use our organisation’s online tools.

I think this demonstrates that there is a lot of variance possible within this simple definition of user story. In the past I think I have over-specified functionality with user stories, leaving my developers with a weird tension between overly specific (and hence out of date) user stories and little or no supporting documentation around other design issues.

This actually speaks to the N in INVEST, as Cat explains it:

“Negotiable: User stories are not a contract; they are reminders for the team to discuss and collaborate to clarify the details near time of development

What a user story really is is a placeholder for a conversation.  We’ve gotten away from writing strict, rigid use cases and into these user stories, which are much better for the way the business world really works.  By writing a user story this way, I am opening up a higher bandwidth conversation.  Instead of a developer just reading what I have and doing it word for word, now we can talk about things and make sure everyone is on the same page and fully understands the business value and the needs of the user.  I like that Kelly specified “near time of development” though; that’s one thing you’ll always find: CHANGE IS A CONSTANT.  Friggin annoying, but it is inevitable.  The closer to development time you talk about something the more likely it is that you’ll have the best information and the most clarity on the item.”

I especially like the idea of a user story as a placeholder for a conversation. Of course this depends on your developers actually being willing to talk to anyone about the requirements (sometimes they still seem to think that it is faster to code away on assumptions and correct later than to have a 30 min conversation up front and ensure you know what you are doing!).

Scott Reynolds works with Cat, and he points out that not everything can be captured in user stories:

“Here’s the thing, stories and tasks are only part of the equation. Stories alone aren’t enough to define a system, and trying to define everything in text is a fool’s task. (I’ve been that fool). You need a full arsenal of specification tools to do the best job possible.”

I think I’ve been the fool Scott mentioned myself (once or twice). Scott (and Cat) mentions 3 other tools that they use as well as user stories:

  1. Mockups
    Basically a low-fidelity prototype. They are great for eliciting feedback about visual design and interaction issues without leaving anyone feeling like these ideas are final. They are poor for actually designing off of as they frequently ignore or skimp on the design of areas that were not pertinent to the original design issues being explored in them.
  2. High Fidelity Design
    High-fidelity screenshots showing exactly how the screen should look. These are great when you need signoff on something from outside the development team as they show everything that needs to be taken into account. They are poor when the design needs to change and you don’t have time to re-do those rich initial screenshots for the change request. Actually they are poor for Agile, full-stop, as they reek of BUFD.
  3. Conversation and Whiteboarding
    This is the higher bandwidth conversation that Cat referred to. This is a chance to meet, collaboratively engage each other and work out what the business need for this feature is. The caveat is that it is only as good as the conversation and whiteboarding ability of your developers, and it requires that the customer be available immediately when the developers need them (this is why Agile doesn’t work for many projects).

There are other good ideas for artifacts to capture interaction design ideas, such as:

  • Acceptance Tests
    Here I mean a light version of the full test scripts that are possible. Ones that match user stories come in the form:
    Given that [context], when [event/action], then [expected outcome].
    Like user stories they have the same problems with being at the right scale.
  • Key Scenarios
    Penny Hagen describes these as combinations of user stories that help define the strategic direction of the website. Whilst she uses them as a tool to help define design strategy early on, they have a useful purpose in helping developers understand the context of the user stories they are working on.
  • User Pathways
    Again Penny Hagen describes these as a detailed view of the pathway a user needs to follow for a key scenario. They don’t explicitly restrict themselves to pages, or data, but they do help identify the user’s view of what is happening when they interact with the system – and give insight into the user’s experience over time.

Personally I’ve used mockups, high fidelity design, conversation/whiteboarding and acceptance tests to varying levels of success. One of the problems you face in Agile development is that the more artifacts you ask for, the longer it takes to go from designing to building – and the greater the chance that your artifacts are out of date and, frankly, wrong.

I’m still not sure about how to set my user stories, I sure appreciate the discipline they grant even quick feature specifications, but I’m loathe now to simply bang them out when the reality is that I might need to use either less, or more, detail for a given feature. I’m going to keep experimenting because that’s what Agile is all about. In the meantime let me know if you find something better to use!


  1. I think that organisations come to Agile because they are desperate for improvement. They think the problem is to do with poor software delivery, but I believe the problem is poor requirements (or if you prefer poor 'user stories'). Which suggests that Scrum/XP solves the wrong problem. There is no real issue with talented developers delivering code. The problem is the business being unable to state what they want clearly. Scrum/XP skirts around the issue of user story management. I think where we go from here is we split into an Agile Requirements practice (ARP) and an Agile Delivery practice (ADP). ADP works well. ARP doesn't. Jacobson's view of the essential issues of concern in software engineering echos this approach. i.e. requirements don't belong in delivery, rather requirements are a formal input to delivery.

    I'm a BA working on ideas for making stories better by the time they get to the Sprint planning meeting so planning poker can be done with enough information to have confidence. I do this using a requirements pattern language I've been using it since 2003 and it works well. The pattern language works for transactionally-oriented database applications and includes patterns for driving out common personas, minimal persistant representation, data maintenance, lifecycle class, and management information.
    The application of the pattern language ensures the upfront requirements work does not take longer than it should. A first cut of the requirements hierarchy tree is always available within a week. The whole set of ‘conversations’ around each candidate user story is almost always done within five weeks – then the sprint planning meeting can start, and it is guaranteed to be short and sweet.
    The implementable story hierarchy has project stories at the top. These are akin to ‘Jacobian’ use cases in that they represent the achievement of the user/actor/persona goal. They are the top level of the requirements ‘tree’ and act as the basis of the requirements table of contents. The project stories decompose into release and iteration stories. The entire hierarchy can be traced back to all the business inputs from interviews and workshops. The approach introduces a new definition of ‘epic’ to no longer mean ‘a big story’ (not that helpful) to a more interesting definition that includes:
    • Enterprise stories
    • Back stories
    • Project stories and tests
    • Release stories and tests
    • Iteration stories and tests
    • Constraints
    • Implementation tales
    • Non-functional requirements
    The definition of ‘epic’ shows how all these elements fit together and is supported by graphics and spreadsheets. This approach is really useful early in the project lifecycle. It can be applied during feasibility, and in ‘ideas management’ where management has to decide which projects to fund in the first place.

    I'm interested in:
    • how to bring the PMO onboard
    • how to reconcile the need for 'governance' with Agile
    • how to give senior management confidence
    • what to do when the customer isn't full time available
    • reconciling enterprise stories, project stories, release stories, iteration stories, constraints, acceptance criteria etc. into a big picture
    • how upfront requirements/stories can still be Agile (keep it simple, but no simpler than it needs to be)
    • a synthesis of Agile modeling and the best lightweight aspects of UML

    I'm blogging at I also write at

    thanks Peter