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.
Example of a User Story
Subscribe to:
Post Comments (Atom)
8 comments:
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
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.
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
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.
Hi,
You could split into smaller user stories as you suggest, and keep them together as one 'theme'...
Kelly.
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?
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.
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.
Post a Comment