Agile Story Writing

agile-story-writing-presentationGathering and defining software requirements is difficult.

One Agile technique to help address this challenge is writing user stories, which are short descriptions of functions that an end-user would want.

While user stories help convert concepts into functions, writing good user stories is easier said than done.

Download PDF

What you’ll learn in this presentation:
  • ebook-what-is-agile1The basics of user stories.
  • How user stories fit into the overall Agile planning process.
  • How to write a user story.
Why is it so Difficult to Determine Software Requirements?
  • Requirements gathering is when informal ideas become formal
    concepts:

    • Converting a concept into something concrete is almost always more difficult than it is initially believed to be.
    • The concept of what the concrete version needs to look like changes frequently.

client-ideas-requirements

Why are Requirements So Important?
  • book-coversAccording to Fred Brooks (the author of The
    Mythical Man Month):

    • “The hardest single part of building a software
      system is deciding precisely what to build. No
      other part is as difficult…No other part of the work
      so cripples the resulting system if done wrong.”1
    • According to Barry Boehm (Software Engineering
      Economics) and other software engineering
      experts, around 75-80% of all errors found in
      software projects can be traced back to the design
      and requirements phases

1Brooks, Frederick P., 1987. “No Silver Bullet: Essence and Accidents of Software Engineering”, Computer, Volume 20, No. 4.
2Boehm, W .Barry. “Software Engineering Economics”. Prentice Hall; 1 edition (Oct. 22 1981).

The Challenges with Written Requirements
  • book-covers-02According to Mike Cohn, author of User Stories Applied:
    • “Writing things down is no guarantee that customers will
      get what they want; at best they’ll get what they wrote
      down.”3
  •  From Lean Software Development by Mary & Tom
    Poppendieck, the Seven Wastes of Software
    Development:4

    1. Partially Done Work
    2. Extra Processes (paperwork)
    3. Extra Features
    4. Task Switching
    5. Waiting
    6. Motion
    7. Defects

3 Cohn, Michael W., 2004. “User Stories Applied for Agile Software Development”, (Addison-Wesley Professional Series, Boston, MA).4 Poppendieck, Mary and Poppendieck, Tom, 2003. “Lean Software Development: An Agile Toolkit”, (Addison-Wesley Professional Series, Boston, MA).

What is a User Story

There are numerous definitions for stories.

  • A common definition:
  • A short description of a function that an
    end-user would want.
  • From Kent Beck:
    • “One thing the customer wants the system
      to do…(it) should be testable.”5
  • From Ron Jeffries:
    • “Stories are promises for…the series of conversations that will take place between the customer and the programmers.”6

5 Beck, Kent, 2000. “Extreme Programming: Embrace Change”, (Addison-Wesley, Boston, MA)6Jeffries, Ron, Anderson, Ann and Hendrickson, Chet, 2001. “Extreme Programming Installed”, (Addison-Wesley, Boston, MA)

Why User Stories?

story-cardsStories have many advantages.

  • Easy to understand
    • Written in non-technical language that customers / product owners can relate to.
  • Work at the right level
    • Not too detailed, are easy to manipulate and move around, like a deck of cards.
  • Relatively easy to create
    • Writing stories takes some skill, but experts can define entire systems for planning purposes in a matter of hours.
Story Types

epic-story-type

Epic

  • Represents multiple features or many stories.
  • Can take months to build and works at the release level.
  • What the end users tend to focus on.

 

feature-story-type

Feature

  • Smaller than epics, but bigger than stories.
  • Can take weeks, possibly one or more Iterations to build.
  • What customers / product owners tend to focus on

 

user-story-type

User Story

  • Are the smallest increment of value.
  • Take days, perhaps a week or two at most to build.
  • What development teams tend to focus on.
Key Players: Customers & Developers

customer-programmer-bill-of-rights

 

Customers / product owners

  • The people who know how to do what the system is going to be doing.
  • They either are the end user or they are representative of the eventual user of the system.

Programmers

  • The people who will be building, testing, deploying, documenting & training those who will use the system.

Stories are key to fulfilling the requirements in the Customer and Programmers Bills of Rights.

User Story Components

 

A typical story card

A typical story card

user-story-components

At minimum, a user story has:

  1.  A card to write the story on.
  2. A name that the customers and developers understand.
  3. A description (should be limited to one or two sentences).
  4. Acceptance criteria to define when the story will be considered completed.
  5. A size estimate for time management.

 

 

 

 

 

 

Story Actions

story-actionsStories can be:

  • Split
    • A large story can be split into two or more smaller ones of different sizes; useful for breaking up epics.
  • Combined
    • Two or more small stories can be combined into one.
  • Added
    • New stories can be added to an existing backlog.
  • Deleted
    • Existing stories can be deleted from a backlog.
The 3 Cs of Stories

card 

Card

  • A token to represent some customer functionality.
  • Stories represent customer requirements rather than document them.
  • Using a card keeps the story short.

converstaion

 

Conversation

  • Customers and developers discuss the details of the story at the
    time it is to be developed, not before then.

 

confirmation

Confirmation

  • The customer should provide acceptance tests for the story, and
    then see them run to confirm that the story has been completed.
User Roles and Description Formats

user-roles

  • Identifying user roles helps with writing stories.
  • Standard story description template:
    • As a [role], provide [function] so that [business value].
  • Some simple examples:
    • As a customer, provide a button that I can use so that I can connect directly with the call centre when my order gets stuck.
    • As a call centre rep., review orders in progress online so that I can help customers complete their orders.
    • As a manager, access stats on incomplete online orders so that I can make decisions on how to improve the ordering process.
Writing Stories – The INVEST Framework7
  • Independent – Dependencies between stories should be avoided.
  • Negotiable – Stories should be written so that the details can be negotiated in a conversation between the customer and the development team.
  • Valuable – The feature should have business value to the customer.
  • Estimatable – Stories should be understood well enough by customers and should be small enough to be “estimatable”.
  • Small – Stories that are too big are not useful in planning.
  • Testable – It must be possible for the development team to write tests for the story.

7Wake,Bill. “INVEST in Good Stories, and SMART Tasks”. Posted August 17, 2003 on XP123.

User Story vs. Use Cases

user-stories-vs-use-cases

  • A story can be considered similar to a lightweight use case.
    • A story can represent a small piece of a use case.
  • Use cases cut across many functions and may touch on many stories.
Examples of Common Story Mistakes

common-mistakes-01 common-mistakes-02 common-mistakes-03

Tweet about this on TwitterShare on LinkedInShare on FacebookShare on Google+Email this to someone