Turning requirements into user stories

If people don’t “get” user story writing, try this simple exercise: Take a non-functional requirement and convert it into one or more stories by looking for the user(s). Here’s an example from a project I did a few years ago:


The Functional Spec included a non-functional requirement for an overnight batch run to create a particular database report. We looked for the users and discovered that this report was for only one person, who liked to begin each day by looking over yesterday’s figures. So we turned the requirement around and wrote it from that user’s point of view. Now we have a user story concerning this chap’s wish to read that report. It completely replaces the earlier non-functional statement, which was clearly a solution, not a requirement.


User stories also free the developers to be creative in providing a solution, because they are focused only on the business need and not on the analyst’s perception of today’s (or yesterday’s) technical constraints. On the project above it turned out to be easiest to build the report on the fly, incrementing it with every transaction throughout the day. This solution failed to meet the original ‘requirement’, but in fact over-delivered for the user, who was now able to view his figures at any time during the day.

Get in touch if your team would benefit from training in how to avoid this kind of mistake.

4 thoughts on “Turning requirements into user stories

  1. Pingback: xpday5 « silk and spinach

  2. Pingback: what is “quality”? « silk and spinach

  3. This is whole concept of User Stories is nuts – providing ambiguous desriptions of requirements to development and expect them to deliver what the customer wants!! really!! – get real… you must discuss and model the customers requirements and produce a Business Process Diagram (BPD)/ Use Case (high-level at least) and then a flow of events – its been my experience that gaps in functionality and poor customer satisfaction arises from poorly spec’d requirements and leaves you open to scope creap whereby the functional requirements from an users perspective are not met because the user story is not completely fleshed out. User Stories are ONLY useful if considered as a high-level 4-line paragraph that descripts a use case. Modelling BPD’s and Use Cases ensure that the complete end-to-end view of a customers requirement can be met – a small paragraph doesnt achieve this.


    • Sorry Steve but in laying the claim that User Stories provide ‘ambiguous descriptions of requirements”, it seems you’ve totally missed the point on what a User Story is.

      A User Story – which, to quote Beck, is ‘a vehicle intended to get business people and technical people talking to each other’ – , is the agreed output of an analyst, a tester and a developer. In your own words, this is where the group “model[s] and discuss[es] the customer’s requirements”.

      The tuple’s User Story is made up of two parts:

      1) The requirement/business benefit, defined using a Ubiquious Language in accordance with SMART: “As a…I want… so that…”
      2) A non-ambiguous description of what constitutes ‘done’: “Given…when…then”

      These are articulated from the perspective of the user and use a non-ambiguous example to articulate the correct behaviour.

      So it therefore follows that that a valid and agreed User Story can never be ambiguous.

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 )

Google photo

You are commenting using your Google 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 )

Connecting to %s