Index cards

Index cards

As noted in User Stories, Ron Jefferies, Agile consultant, suggested that there are three attributes of a user story: the Three “C’s”. They are card, conversation and confirmation.  One of the earliest instantiation of the user story was as an index card. The use of card served as a constraint, which enforces brevity, increases the flow of work and reenforces the need for conversations.

Most classic methods mandate that requirements are documented early in the project and that they are as complete and detailed as possible.  This means that individual requirements tend to have a significant word count.  I have read (ok, and helped write) use case documents that exceeded 20 pages.  Substantial portions of those documents were done as requirements.  Written words only convey so much understanding and the marginal utility of adding more words is generally low.

Smaller pieces of work can be completed more quickly than larger pieces of work (assuming the same level of complexity).  Additionally, small pieces of work are easier to understand, therefore need less investigation. Also, since they can be completed more quickly there is less of a chance being interrupted for a higher priority piece of work. Due to the speed with which the story can be completed,  you can confirm that the work does what is expected and generate feedback faster too.

Because stories do not pretend to be complete they not only invite conversation, but rather require it. Conversations are exchanges of thoughts, opinions, and feelings that take place as the stories are estimated, planned, analyzed, developed and tested.

In order to attain these benefits a story card need to include:

  1. User Story – The simple need, generally in the “Persona, Goal, Benefit” format.
  2. Acceptance Criteria – Acceptance criteria guides the team to deliver the functionality that the user actually needs and wants. Each story typically has two to five acceptance criteria. More is generally an indication of the need to split the story into smaller pieces.
  3. Estimated Size – The relative size of the story allows the team to determine whether they can accomplish the story during the sprint. Sizing mechanisms, such as Story Points, Quick and Early Function Points or Ideal Days, are used to generate velocity and are used in both sprint and release planning.
  4. Annotations – Annotations, including clarification and other information, are needed to help the team deliver value.  Examples of annotations that can be added to a story as it evolves might include wire frames or paper prototypes.

Software tools have reduced the story card to a metaphor, in some cases. However the concepts of brevity, granularity and conversation are just as relevant, whether we are using a 3×5 piece of paper or a software tool.