User Story Example

Example of a User StoryI recently described User Stories and the composition of a User Story Card – Card, Conversation and Confirmation.

I’m not really sure if you would consider this user story example to be good, bad or indifferent – I guess it depends what you’re used to – but here is an example nevertheless!

This is the front of the card.

The Card section describes the user story. The Conversation section provides more information about the feature.

Note the feature (for a user to log in to a web site) is small, so the story can be fairly well described on a small card.

Clearly it’s not as detailed as a traditional specification, but annotating a visual representation of a small feature at a time, makes it fairly self explanatory for team members.

And I would certainly argue it’s more easily digestable than a lengthy specification, especially for business colleagues.

Here is the back of the card:

The back of the card outlines the test cases for this feature – how it’s going to be confirmed.

Whether or not these are the right scenarios, or cover all possible scenarios, isn’t really the point of this example.

The point is that the test cases for this feature are written on the back of the card, in support of the information about the feature, and before the feature is developed.

Generally speaking, there is a very fine line between a requirements scenario and a test case, so it isn’t necessary to capture too much detail on the front of the card and clutter it up. The card in its entirety represents the requirements for the feature; whether captured in the Conversation section or the Confirmation section.

Even the description of the user story in the Card section carries some important information. In this case, there is a pre-condition (the user must be registered) and a post-condition (the user can access subscriber-only content). All of the card must be read to get the whole story.

Importantly, the User Story is expressed in business language, and in a micro, more easily digestable, information-packed format.


28 Responses to “User Story Example”

  1. James Roberts says:

    Hi Kelly,

    I think this is a great example of future development methods, do I see a combination of traditional storyboarding+use case analysis? If a problem has been specified in those simple terms then it should easily be understandable by all even though some may not have seen the entire picture, so to speak. I guess I’m not explaining myself very well, however I think you could leave a card like that on a developers desk at 9am and they should be able to finish it by 5pm with minimal error, they’d not even need to know what project they were working on … only the language!

    I really think this could work if one could just leave a card on a developers desk for thier daily task, they do not need to worry about the rest of the project or how it impacts on the business … the programmer just needs to do thier bit. You’d need a system builder/integrator that puts all the pieces of the project together … “team jigsaw” At each iteration of development everyone has a go at adding thier piece to the picture; over time things become clear.

    Thanks for getting me thinking,


  2. Kelly Waters says:

    Yes, in this way it also supports distributed development teams better, and also improves the possibiliy of re-using this feature elsewhere if it’s delivered in a re-usable format, such as a web control with a service behind it.


  3. James Roberts says:

    I think this card idea is fantastic – developer post-it notes, great for the sales manager etc. Just so long as someone does not change the card into an A4 form.


  4. Anonymous says:

    Hi, I am not sure how to manage big requirements in this sort of requirement gathering. I feel for small user stories it works perfect. But when there is more to say and need a bigger picture, i am not sure how to address it. You may suggest user stories should be broken or make a smaller stories, but if we adapt such a method there will be more user stories for one scenario. Please can you advise me how to handle such situations.

  5. Kelly Waters says:


    You could split into smaller user stories as you suggest, and keep them together as one ‘theme’…


  6. Paul Halverson says:

    I’ve just started learning about agile and I have the following observation – As a designer, I like to break work down into building blocks – such that I create an infrastructure as I go along that I can reuse for other jobs in the same system. It seems that in Agile I would still want to go through the set of User Stories that I have in my backlog and separate out the important building blocks – and use that information as a guide to how I implemented my user stories. This analysis would also affect the sizing of the user stories in that if I develop one user story that gets a few building blocks and then develop another user story that uses those building blocks, that second user story would require a smaller sizing…
    Any ideas on this?

  7. Kelly Waters says:

    Hi Paul

    Agile purists would say don’t look too far ahead, because things have a habit of changing, so too much up-front analysis can be a waste.

    Instead, build one feature at a time, and if (for example) on feature 2 you find something in common with feature 1, “refactor” feature 1 by pulling out the common building blocks and use it on both features 1 and 2.

    Keep going like this as you work through your product backlog, and you will only produce building blocks that are definitely needed, regardless of what might change in future, and you will not waste any time analysing and designing features that may not get done if priorities change.

    Of course if you have a high degree of certainty about features (not looking too far ahead), and you can see they have something in common, it would make sense to design it with some of the important building blocks in the first place.

    In my view that’s absolutely fine and it’s about finding the right balance that works for you. However I would certainly encourage you not to go into too much detail too far ahead, and not too think of refactoring as unnecessary re-work as it saves an awful lot of time compared with trying to understand everything up-front.

    Hope this helps,


  8. utahkay says:

    I like this example. I think it would be improved if the story card were handwritten. This would clearly show the concept of low-fidelity prototyping.

    One of the things I love about Agile methods is that it’s so easy to get collaboration! Because now we’re drawing all over 3×5 cards and whiteboards, as opposed to typing up one person’s “rough draft” and handing it out.

  9. Roger L. Cauvin says:

    This example of a user story is very granular and has delved into interaction design. I’d say there’s very little here that could properly be characterized as requirements. (The very notion of having users log is design.)

    That doesn’t mean the story isn’t useful. But I think it’s important to have a separate set of stories that express the real requirements.

  10. Paranitharan S says:

    I have found it very useful in understanding the basic principle of user stories and the user story Card implementation will really help me.

    But, I need help on splitting a user story into small stories. I have one complicated screen will difficult business logic. How can I split this story? Is there any ground rules for splitting user story?

    Can I define development of UI as one story, then implementing validations as another user story and finally the business logic as one story?

  11. Kelly Waters says:

    Try not to split the story into tasks (eg UI, business logic, testing, etc) and instead split into functional breakdown. For instance, s an example of how you might break down a large data-entry form…

    As a [who], I want to [enter my information], so I can [whatever].

    As a [customer service dept], I want to [make sure name and address is always entered] so I can [dispatch goods].

    As a [marketing dept], I want to [make sure email address is always captured] so I can [send information about other products and services].

    As a [who], I want to [check other details] so I can [capture all the important information needed later].

    These obviously are just examples. In this case, I would say your overall form is a ‘theme’ (set of user stories), or even an ‘epic’ (big user story). If all the smaller user stories are required before anything can be shipped, you can clip the user story cards together or keep them in one row on the whiteboard.

    When the last card is done, you are ready. But in the meantime, completion of the smaller cards gives you a clear view of progress and potentially allows the work to be taken by multiple people.


  12. alen says:

    You forgot to add an example of "Confirmation" part on the card…

  13. Kelly Waters says:

    Hi Alen – actually Confirmations are shown on the example back of the card… Take another look above and you can see some success and failure scenarios.


  14. Archana says:

    I have a basic question. Everybody says that user stories should be independent of the order. So when we look at the estimates of the user story like "As [a registers user], I want to [login], so that I can [view and edit the data]".
    Are we assuming that the database for the user profiles, actual content data management etc are all ready?
    Isn't it a huge task to do these basic infrastructure tasks, before any of the user stories can even be looked at?

  15. Bhavtosh says:


    even im new to agile but i feel the DB model can be created by logically combining the collection of approved user stories as it will help in keep and maintain data in a relative manner

    more over the DB activity can be done as normally as being done with other models like sprial, iterative, RUP etc

    if you get more information then do pls share about it


  16. Anonymous says:

    We are still looking for *real* stories from real projects. "As a user I want to login" isn't very insightful … being honest. It's more helpful to see Agile explained with real examples.

    Thanks for this post.

  17. Vinodhini says:

    Hi Kelly,

    I am currently getting myself updated about scrum and writing good user stories with just-enough-details. It will be great if u can give me your inputs on the following scenario. For example I will take my Epic as to create a new screen to input candidate information. This screen should have few subsections within this, such as Personal Information, educational qualifications, experience etc. Also the user should be able to add, edit and delete these records. When I am breaking down this Epic into user stories how can I select the level to break. If I break it down to sub section wise will that be enough or should I break it further to add, edit and delete for each subsection as separate user stories.
    After creating the user stories when should I discuss the fields which we are going to have under each subsection? Should this be done at the sprint planning meeting or prior to that? That is when I go for the sprint planning meeting should I go with a wire frame? They say that before the sprint planning meeting no detailed level planning should be done. However on the other hand it says ideally the sprint planning meeting should not take more than 4 hours…
    For any field validation related stuff I guess I don’t need to write separate user stories and this will be discussed during the planning meeting…


  18. Kelly Waters says:

    Hi Vino. For long questions, like this, it might be worth posting on my agile community where other people would be able to tell you about their experiences too. You can find it here:

    From my perspective, I think how much you break the user stories down is very much a matter of opinion. Ideally try to break them down small, but not so small they start to become heavily inter-dependent.

    Also, try to think of them from a user's perspective. I don't think a user would ever ask for fields to be validated, so I don't think field validations make good user stories. Sections of the form, on the other hand, might well make sense to split, if the form is big enough that it would be a bit unwieldy as one.

    The team discuss the details of each user story during sprint planning. If, however, you have an analyst or product manager, it's entirely reasonable for them to work a bit ahead of the team and pull together some of the basics beforehand to speed up sprint planning for all involved. Wireframes would probably be ideal for this, as you don't want to go into sprint planning with the feeling the user stories have been completely nailed down. It's important for the team to contribute and have the chance to influence them too.

    Hope this helps,

  19. mike says:

    This just seems like it takes things to the level of flash cards for children. Are designers/architects and developers really this pathetic? The same exact thing can be written in a spec. if these learned to write as well as design/architect and develop

  20. Kelly Waters says:

    Hi Mike. Of course they can be written in a spec. The point of user story cards is just that you only write the bits you need as they are about to be developed. You don’t write them all up-front in a long document.

    That’s all it is really, but it’s amazing how empowering that is, how much faster you can start delivering something to test, or even some benefits, and also how you are then much more able to respond to change, i.e. be agile.


  21. John Ortiz says:

    Thanks for this information. It is useful and easy to understand. I’m trying to create a little information system for a parking. Agile approach is appropriated for that system? Thanks in advance.

  22. Kai says:

    1. Where do u store ur cards?
    2. How would u write this for a backend process
    3. How would u write this for a maintence of an existing system that needs functionality revised.

    can u email me ur response..thanks

  23. Manilal says:

    Hello Kelly,
    I have the following scenario:
    There are three roles identified for the system: Owners, Employees and Customers.

    Owners and Employees share some common user stories. So my question is :

    Is it possible to create an user story like the following:

    As an Owner/Employee I want to see all tasks assigned to me.

    Please let me know if this is a valid user story.

  24. Reggie says:

    User stories may be a blessing or the very flaw that dooms your project.
    Some Agile advocates push for small user stories that describe a functional block, creating 15-30 stories per such. Then these are delegated to different BAs/Devs to work on and often happens that critical parts of the functionality were missed. This is especially important when you try to develop new system for existing processes.
    User stories should be taken very seriously, thought out, tested (yes tested). Start at very High Level, then break down. If you start with many mini stories that try to describe same functional block of process you will run risk of missing many important pieces. Devs also won’t help as each will think in case they found something missing that it must be then in another story, so no worries…then bad surprise late in the Dev process.

  25. mrtawanan says:

    Who develops and keeps the big picture User Story? And how can end user know that the end to end user need is captured and reflected in the user story?

    How does Agile document the Business Process Architecture?

  26. Kelly Waters says:

    The product backlog, and the user stories on it, are the responsibility of the Product Owner. In larger organisations, this is sometimes delegated to Business Analysts or maybe done as part of a Product Owner team rather than one individual. In this case, some organisations have the idea of a Chief Product Owner that the other Product Owners report into. Ultimately, whatever you call them, it’s the domain of your product management people.

    The only way of really knowing for sure whether a user story has actually captured the entire end to end user need is to test it on users. Some organisations involve real end users throughout the development process, or at least have real end users involved in user testing right from the start and throughout the development. The process of user and usability testing can start with paper prototypes to confirm a concept and get feedback, right the way through to using the completed software at the end of an iteration or release.

    Agile does not include anything specific about how to document anything. Agile methods tend to advocate that you produce whatever documentation is appropriate in your own individual situation and that it should ideally be lightweight, visual, and captured collaboratively just in time for development to begin. In my experience, it is common to have some high level documents over and above the product backlog. These documents might include a high level vision, some high level design concepts and sample web pages (for example) – they might also include a high level architecture (at least the key blocks) and an outline of the business process or workflow that the stories are supporting. The only thing agile would generally push back against is trying to produce detailed documentation about the entire system all up-front.


  27. Kay says:

    This was indeed VERY helpful in assiting to understand “user stories”. I especially like the Confirmation break-out. That was awesome!

    “Two Thumbs Up”

Leave a Reply

What is 10 + 6 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)