When XPers started using 'user stories' to drive development, they were very simple things: one or two sentences on a 3x5 card, possibly with some testing ideas on the back. Very nice... and they work well for small, cohesive, independent, highly-skilled, empowered teams.

Many of the teams I work with aren't like that - especially the independent and empowered part - and they live in organizations that don't understand how such a simple artifact could be enough. In fact, in large organizations with a need for consistency across teams, they often aren't enough.

Let me tell you what I think is enough - I'll give you my template... it works for all manner of stories, from epics to right-sized user stories, to analysis stories, infrastructure stories, and so on.

In all cases, since a story is "a promise for future conversations", all the attributes for a story are simply there in order to have the right conversations in the future. As you read along, try to see how each attribute contributes to the conversations.

First of all, there are some required fields, as follows:

Description (required): A sentence (or two) describing the purpose of the story in enough detail to have the “right conversation” when appropriate. This is often in Cohn form: "as a {role} I want {something} because {reason}."


Size (required): an estimate of effort for the story, usually represented in NUTs (Nebulous Units of Time) like Story Points, t-shirt sizes, etc. However, if the story is an epic, I prefer to just use the word "epic" as its size


'Done' Criteria (required): our actual contract, our validation criteria, how we'll know we're done. This includes both process actions, like "code review" and "unit tests spanning the interfaces", and functional criteria, like "works for case credit card is valid". This takes the place of, and extends, the list of tests we find in a simple user story.


Tasks (required): Finally, the list of tasks that will performed. I treat this as required, some high-performing teams leave it out... just sayin'

But what makes this really work in a large organization are the optional fields, which are:

Title (optional): a simple, intention-revealing moniker for the story - usually used for reference in a spreadsheet or some other tool.


Story Boss (optional): the team member responsible for managing the story to completion


Origin (optional): the source of the story; if it's part of an epic, the epic's name


Dependencies (optional): other stories that depend on this one, or that this one depends on. Don't get carried away with this attribute, it can turn into a sinkhole - it's better to leave it out than over-analyze it, IMHO.


SMEs (optional): a list of people who "know about" this story; who we go to for help when working on it...


Value (optional): a statement of how much this story is “worth”


Notes (optional): whatever you want (or need) to help in the conversations the story represents

It is my contention that this template can help large teams become more consistent with their estimates, more consistent with their process (especially if the "done" criteria is similar across teams), and enable team members to be able to move from team to team more easily.

Try it, let me know what you think...

Dan ;-)
dan@danube.com