Example of a User Story
by Kelly Waters
I 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 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.
21 January 2008 10:13
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,
James
21 January 2008 10:14
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.
Kelly.
21 January 2008 10:16
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.
Regards
James
23 May 2008 11:21
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.
23 May 2008 14:56
Hi,
You could split into smaller user stories as you suggest, and keep them together as one 'theme'...
Kelly.
2 July 2008 21:42
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?
3 July 2008 20:37
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,
Kelly.
27 July 2008 03:42
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 3x5 cards and whiteboards, as opposed to typing up one person's "rough draft" and handing it out.
16 February 2009 15:49
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.
2 March 2009 05:42
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?
2 March 2009 09:06
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.
Kelly.
15 June 2009 09:26
You forgot to add an example of "Confirmation" part on the card...
15 June 2009 11:49
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.
Kelly.
26 August 2009 17:32
Hello,
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?
3 September 2009 09:25
archana,
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
hth,
bhavtosh
22 October 2009 10:34
We are using BDD to specify user stories
http://www.targetprocess.com/blog/2009/10/bdd-and-user-story-specification-examples.html
26 October 2009 23:14
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.
9 March 2010 08:37
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…
Regards,
Vino
13 March 2010 14:08
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:
www.agile-community.com
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,
Kelly.