What makes a good user story
Join the DZone community and get the full member experience.
Join For FreeLeading on from last week where I described that there are two main parts to user stories, the user (or persona or role) and the story (a short description of the intended functionality), this week's blog is intended to focus on specific details on how to write good stories.
The three C's
Most of you are already aware of the 3 C's i believe originally
conceived by Ron Jefferies - Card, Conversation and Confirmation.
Card
The card is important in that User Stories are meant to be written on
Cards. My interpretation of the card metaphor is that Stories need to
be short and concise enough so that they can fit on a single card. It's
imperative that Stories are small enough such that they can be
estimated and completed in a single iteration. When teams struggle
to come up with estimates, this is usually a good sign that the story
is too big and should be broken down. It's good sometimes, however, for
longer term planning to have large stories i.e. epics or themes. But
these need to be broken down into small enough chunks as they get
closer to being prioritized into a sprint.
Another great feature of the Card metaphor is that it's meant to be
very
visual. It's always great to walk into a Scrum room and see the cards
on the wall. At a glance, you can see the story, the estimate, how much
time is left, and what state it is in (open, in-progress, in-test,
accepted). Cards also provide the sense that they're dynamic i.e.
they can be changed, updated, moved, and trashed. That's the whole idea
behind the Agile philosophy - to accept and embrace change.
Conversation
What makes the Conversation so important is that the conversation is
much more important than the story itself. That being said, it's
still important to get the story right. Another thought on why
Conversation is one of the 3 C's is that conversations are usually
understood by all parties i.e. developers and customers alike. It's
important that the story description is written in the customers eyes
as this is most easily understood by everyone and so as not to get
confused by technical jargon.
Confirmation
The C in confirmation is all about identifying up front what is going
to make the customer happy and accept the story as completed. By
definition, user stories must be testable. By providing the test cases
up front, the team is properly setup to succeed. This really helps to
prevent churn and back and forth with the customer at the end of the
sprint.
Capture
There are many ways in which to capture (dare I suggest this is the
fourth C) user stories. The best way I find is by way of User Story
workshops. The reason I like workshops is that it's cross functional
and it generates lot's of "Conversation". And especially if you're
trying to capture a lot of user stories in short while, this is by far
the best approach. There is nothing like a good brain storming session
to get the creative juices flowing. Other ways include interviewing end
users, watching users use the software, competitive analysis etc.
Backlog
An interesting article I saw recently on user stories asked the question
"is there need for an Idea Log?" i.e. a separate log for ideas to be
formulated before going into the backlog. My opinion on this is that
you never know when and where the next great story is going to come
from. Every idea is probably a good one and should be considered. I
still believe in a single backlog to manage all user stories. Even if
it get's a little out of hand. In this case, one can consider initially
grouping multiple user stories to make it more manageable. And then,
when the story is considered high enough of a priority, the story can
be dis-aggregated into smaller ones. There's a certain importance
suggested when telling customers "it's on the backlog". If it doesn't
go on the backlog, folks are going to stop coming up with ideas.
Story template
Finally, when you write user stories be sure to include the benefit,
i.e. "As a frequent flyer, I'd like to redeem my air miles because
they're about to expire". The reason for the benefit is that it adds color to the
story and helps the developer to understand the intent a little better.
Written by Jack Milunksy - COO at Brightspark, certified ScrumMaster and Co-founder of Agilebuddy (Agile project management software that lets you easily Create, Estimate, Plan and Track your software development projects). For great Agile tips follow Jack at: www.twitter.com/agilebuddy. To get more info on Agilebuddy please visit: www.agilebuddy.com
Opinions expressed by DZone contributors are their own.
Comments