Agile Method: The Stories

Agile Method: General Overview

There are several types of stories, but they all share having a goal, being estimable (or breakable into estimable elements), and having a clear definition of “DONE” (a clear end).

These units allow a project to be broken down clearly so it can be carried out as efficiently as possible.

Note: This post was translated from french with the help of AI. The original post was written with the knowledge of a younger me.

Here is a (non-exhaustive) overview of the different types of stories

• Task: Not really a story per se, but it is the atomic unit on which a story is built. It should be as simple as possible. For example, if the story is “entering a house,” the task is “place the hand on the door handle,” the next task “turn the handle,” etc.
• Story: This is the most well-known type of story in agile methodology. It is focused on interaction with the end user. To avoid confusing “histoire” and “story” in English, the term “User Story” is preferred. It allows the realization of a feature.
• NFR: This type of story is the hardest to define. NFR stands for “Non-functional requirements.” These are all actions necessary for the smooth running of the project but do not affect the end user’s interaction with the project. For example, code refactoring, a license change, setting up a new development server, or a coffee machine for the team.
• Spike: This story formalizes research steps. It has a different definition of DONE than others because research inherently involves uncertainty.
• Epic: This definition varies depending on who uses it. Generally, it defines a story whose estimation exceeds the capacity of a Sprint. It must therefore be broken down into smaller stories.
• Initiative: Used by JIRA. It groups together a set of Epics linked by a common goal.
• Theme: This story groups Epics or Initiatives whose completion represents a major change for a large part of the organization (or company).
• Saga: This term is rarely used (but I like it) and can be confused with Theme or Initiative. It gives a sense of continuity akin to “epic.” It can define the root of the project, the story tree. Therefore, I suggest calling the story tree “Yggdrasil” to remain consistent in terminology.

Story Start and End

Each story must have a clear definition of READY (or TODO) and, most often, DONE.

That is, the Product Owner and the agile team must agree on the prerequisites for starting the story (READY). For DONE, they must define the criteria that ensure a story is truly finished. Note that stories like Epic, Theme, Initiative, or Saga do not have a DONE definition other than the DONE of all the stories they comprise.

Some Stories in Detail

User Story

The most well-known story in agile methodology. This type of story creates functional value for the end user.

Definition of READY: A story must have a clear start according to the INVEST acronym below:

• Independent: Each story must be independent of any other task.
• Negotiable: Each story should be discussable to best describe the user journey it provides:
  • Given a state
  • When an action
  • Then a result
• Valuable: Each story must deliver actual value to the product from the perspective of the end user.
• Estimable: Each story must be estimable in terms of complexity points, leading to a time estimate.
• Small: Each story should be small enough to be completed by one or a few people in a Sprint.
• Testable: Each story should be testable within a continuous integration testing tool.

Definition of DONE: A story must have a clear end defined in advance with specific objectives.

Example of DONE:

• Generated documentation
• Functional tests passed
• Security tests passed

NFR

NFR is an agile story type that does not focus on the end user.

NFR stands for “Non-functional requirements.”

It addresses tasks necessary for the smooth running of the project but invisible to the end user.

Examples:

• Legal issues
• Security issues
• Organizational issues
• Performance issues
• Infrastructure issues

An NFR is similar to a Story, except it is not focused on the end user.

An NFR must be SMART:

• Specific: understandable by everyone
• Measurable: with a clearly defined DONE (objective)
• Achievable: feasible
• Relevant: pertinent
• Time-Boxed: short-term and estimable in complexity points

It must have a clear definition of READY and DONE.

Spike

Used for research in agile methodology.

A Spike (the tip) aims to clarify steps, knowledge, and time needed to resolve Stories and NFRs.

It must be independent and testable, but by nature, it is not estimable. Indeed, in research, the outcome is unknown, making estimation impossible.

To address this, it is time-boxed (with a defined time).

Example: Researching a CouchDB replacement in 24 hours (3 days)

A Spike must be SMART:

• Specific: understandable by everyone
• Measurable: with a clearly defined DONE (objective)
• Achievable: feasible
• Relevant: pertinent
• Time-Boxed: short-term

It must have a clear definition of READY and DONE.

The DONE in this case defines the goal and research direction. It helps determine whether the research is valid.

For example, if the goal is to find a new method for making a raspberry pie and the research results in methods for making cat kibble, it is not DONE.

Sources

• Scrum Expert
• Atlassian