Agile Story Writing

• The basics of user stories.
• How user stories fit into the overall Agile planning process.
• How to write a user story.

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.

According 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.”¹
• 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

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

According 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.”³

From Lean Software Development by Mary & Tom
Poppendieck, the Seven Wastes of Software
Development:⁴

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

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

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.”⁵
• From Ron Jeffries: “Stories are promises for…the series of conversations that will take place between the customer and the programmers.”⁶

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

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

Stories 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.

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

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

• • • 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

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

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.

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

At minimum, a user story has:

1. 1. 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.

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

At minimum, a user story has:

1. 1. 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.

Stories 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.

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

Conversation

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

Confirmation

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

Stories 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.

• 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.

Stories 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.

• 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.

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

Stories 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.

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.

Stories 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.

Mike Cohn’s site contains a good section on user stories:
http://www.mountaingoatsoftware.com/agile/user-stories

The Agile Alliance site is also a good resource:
http://guide.agilealliance.org/guide/user-stories.html

Intelliware’s Knowledge Centre contains several resources on the basics of Agile:
http://www.www.intelliware.com/knowledge-centre