Jul 9, 2021
Recently, Sam and Dan discussed
velocity; an important metric to agile teams, and what it looks
like when used correctly vs. incorrectly. In keeping with this
theme, they’re exploring two other important metrics that are also
often misused and misunderstood: story points and user
stories.
Story points and user stories
are all-too-commonly misused. In this episode, Sam and Dan debunk
some of the common misunderstandings, share how both concepts are
often misused, personal experiences in their roles as agile
coaches, and how to correctly use them.
Key Takeaways
- What are user stories? How can they be
misused?
-
- User stories come from extreme programming as
one of the practices that were advocated for during its
emergence
- User stories were born out of a need for
telling a story about what the users want the system to do (and use
that instead of the detailed requirements documentation that
nobody actually reads)
- Kent Beck is attributed to coining the term
“user story”
- User stories have good intentions and work in a
particular context but are often misused and come with a multitude
of unintended consequences
- If the user story framework helps you,
great — but if it doesn’t, don’t use it (don’t think
that you have to use it because it “makes you agile”)
- The idea of the user story framework is to
concisely suggest to developers what a user might want to do with a
system (it should also answer: What kind of user? What kind of
behavior? And why?)
- Good vs. bad uses of utilizing user
stories:
-
- Misuse: If you simply want to do something as a
developer, put a task in your backlog; you don’t have to twist it
into a user story format
- Misuse: Writing everything down and believing that the problem has been
clearly communicated (Just
because it is written down, doesn’t mean there is a shared
understanding)
- Correct use: When user stories are used to have
a conversation about what we want the system to do or what the user
wants the system to do
- Misuse: If the user story is short enough, it
isn’t necessary to have an abundance of written documentation (If
you’re finding yourself needing to attach a lot of written
documentation to the requirement, it is most likely too broad of a
scope for a user story)
- Misuse: You don’t need to know all of your
stories ahead of time to get the project done
- Correct use: Understand that in creating user
stories and moving through your agile journey, many of them will be
wrong and it’s unknowable
- Correct use: Conversations should be happening
more frequently and be broken down into smaller pieces so that
everyone has a clearer picture
- Tips for leveraging user stories
effectively:
-
- Get in the mind of the user so that you can
better come up with some strategies for appealing to their needs or
fulfilling their needs
- Address the acceptance criteria/conditions of
satisfaction (i.e. How do I know when I’ve achieved this
goal?)
- Try to make the user story about what the user
is trying to achieve (i.e. conditions of satisfaction)
- Reference User Stories Applied: For Agile Software
Development, by Mike
Cohn
- Don’t take user stories too
seriously
- Remember the three Cs: Card (because they used
to be written on index cards), Conversation, and
Confirmation
- Good vs. bad uses of story points:
-
- Misuse: Story points are often conflated with
days (i.e. how long it will take to do something) which, in turn,
become used for velocity metrics (which is then often weaponized
against the team [listen to episode 135])
- Misuse: You shouldn’t be predicting too far out
with story points (instead, talk about what you can do in the next
couple of sprints and then go from there)
- Misuse: Similarly to user stories, don’t take
story points too seriously (i.e. don’t take them as means of
precision beyond having had a conversation around something that is
possible to do)
- Correct use: Story points are simply unitless
measures of relative size (in sprint planning you can worry about
the finer details and granular approach)
- Misuse: There is no value in breaking up story
points into multiple points, resizing the stories, etc. (It’s
supposed to be a close-enough/estimate… it’s not supposed to be
precise)
- Misuse: Software development is unpredictable
and filled with unknowns, trying to force specific predictions with
story points is counterintuitive
- Correct use: Breaking things into smaller
pieces with user stories is a lot easier to figure out the size of
the task
- Closing Thoughts:
-
- Don’t take user stories and story points too
seriously
- Don’t think you know more than you
do
- Cut yourself some slack and cut your team some
slack
- Break things down into smaller and smaller
pieces
- The smaller something is, the more easily it’s
understood and the fewer unknowns there are
Mentioned in this Episode:
Agile Coaches’
Corner Ep. 135:
“Exploring Velocity: What is iI? How Do We Measure It? How Can We
Leverage It?”
Lean Coffee
User Stories Applied: For Agile
Software Development,
by Mike Cohn
Killer Nashville
Devil in a Blue Dress: An Easy
Rawlins Mystery, by
Walter Mosley
Want to Learn More or Get in Touch?
Visit the website and catch up
with all the episodes on AgileThought.com!
Email your thoughts or
suggestions to Podcast@AgileThought.com
or Tweet @AgileThought using
#AgileThoughtPodcast!