New to agile? Remember a user story is more than a card!

What’s wrong with the user story on the card?  It seems to have everything we need: a) short title, b) a size (in this case 2), and c) a well-written story using the standard “As a … I want … so that …” format.  So what’s wrong? Nothing!  Well, almost nothing.  The user story card is a great STARTING POINT, but it is not sufficient by itself.

In coaching Agile and Scrum teams I see many of them starting out with the assumption that the user story card contains all the information they need in order to create a high quality piece of software.  Forgive me for being harsh, but how stupid is that?  Assuming a single sentence can fully describe something which might take a few days to analyze, design, code and test seems pretty ambitious.  No, let me take that back.  It’s more than pretty ambitious, it is just not possible. So I ask again, what’s wrong with this story card?

And again I’ll answer that there is nothing wrong with it, but it is a STARTING POINT.  Many people are familiar with the phrase “INVEST in good user stories” which is an easy way to remember to use the INVEST acronym for guidance when creating user stories.  I wrote a blog entry about that titled “New to agile? INVEST in good user stories”  Web searches lead people to that blog entry many times every day.  But it isn’t sufficient!  If you read agile literature for any period of time you will eventually see the phrase “A user story is an invitation to a conversation.”  This is vitally important to success!  A conversation allows more description than a single sentence.  It can clarify many aspects of the user story.  Taking this a step further we also need to be able to confirm the user story is completed.

Taking all of this together we end up with the 3 C’s of good user stories: Card, Conversation, Confirmation.  Ron Jeffries wrote about this all the way back in 2001 and his advice is still good today.  Agile and Scrum teams need to remember the card is the starting point.  It leads to a conversation where more specifics are given and negotiation (the N in INVEST) can occur.  All of that leads to confirmation in the form of tests (the T in INVEST).  A good story card will likely end up with a back side covered with results of the conversation(s) and confirmation tests.

Next time you see a user story card don’t ask yourself if you need to have a conversation about it.  Instead just assume you need to have a conversation and have it!  Go to the Product Owner or customer or customer proxy and ask to discuss the story.  Make notes for yourself.  In fact it is even better (vital in my mind) to have the conversation involve a developer, tester and product person.  I call them 3-headed conversations.  This allows everyone to be on the same page so later there is no disagreement about what was really meant by the story.  This avoids one of my least favorite conversations which happens when the tester and developer disagree about what the requirement means AFTER the code is written.

If you are using an agile lifecycle management tool rather than physical cards, record the decisions made during the conversation and any resulting confirmation tests in various fields in the tool.  You must make sure the information is captured in case someone else who was not part of the original 3-headed conversation ends up doing some work on the story.

Try using the 3 C’s and see if your results improve.  I’m sure they will.

Until next time I’ll be Making Agile a Reality^® for my clients by continuing to train and coach them to use the 3 C’s effectively.