Create a story

Create a story2018-10-03T17:18:20+00:00

Create Story Workflow

Context

Summary

Provide a summary of this practice.

User Stories are the basic unit of Agile work and delivery.

Purpose

What is the overall goal or intention of this practice?

User Stories are used throughout the delivery cycle:

  • to define (at a high level) the results the team need to achieve.
  • to provide the starting point for a discussion with the user, through which the development activity will actually be carried out.
  • to set Acceptance Criteria.

SLA

What are the schedule, cost, quality, performance or other expectations for completing this practice?

N/a.

Exit conditions

What must have happened or been delivered for this practice to be considered complete?

A story has completed its lifecycle when working software has been created that meets all the criteria identified in the SLA.

Entry conditions

What pre-conditions must be met before this practice is used?

N/a: Stories evolve continuously, from high level ideas and aspirations to detailed definitions.

Outline process

This view shows a simplified version of this process. For full details, explanation and advice, click on the ‘Detailed process’ tab. For background such as entry and exit conditions, click on the ‘Context’ tab.

#StepInstructions
1Define the story.
  1. The team collaborate with representatives of the various user roles to define the ‘stories’ they want to be implemented.
2Story clear?
  1. If the team believes the story is clear enough to proceed, go to Agree Acceptance Criteria.
  2. If not, create a Spike.
3Create a Spike
  1. See here.
4Agree acceptance criteria.
  1. The team agrees Acceptance Criteria for the story.
5Validate story quality.
  1. Check the story against basic criteria for a well-written story.
  2. If it fails to meet the criteria, rewrite it.
  3. If the iteration task plan is already in place, validate it against the team’s Definition of Done.

Detailed process

#StepByOutputInstructionsNotes
1Define the story.Developer.

User.

Draft story.
  1. The user and developer collaborate to define the ‘story’ they want to be implemented.
Any team member may prepare stories.

Stories are written in user language, not technical language.

Stories should use the Actor-Description-Benefit format:

  1. As a <who: role>,
  2. I want <what: function, action, information, etc.>
  3. So that <why: wider benefit or purpose>.

Note that ‘As a user’ or ‘As a manager’ is usually too weak a definition of the Actor segment. Try to specify specific roles that explain why they want this specific function or have a specific benefit in mind.

Any of these items can be elaborated to any degree, limited only by:

  • The user and developer agreeing that they agree on what the story means.
  • The story meets the team’s Definition of Ready (for development).

For further advice on how to write stories, click here.

For tools for documenting stories, click here.

2Story clear?Team.
  1. If the team believes the story is clear enough to proceed, go to Agree Acceptance Criteria.
  2. If not, create a Spike.
If the story involves new stakeholders, review Manage stakeholders
3Create a SpikeDeveloper.

User.

  1. See here.
4Agree acceptance criteria.Team.

User.

Developer.

Acceptance criteria.
  1. The team agrees Acceptance Criteria for the story.
The team as a whole must agree the Acceptance Criteria, because:

  • They embody a much wider range of experience, and are more likely to identify issues than the individual user and developer alone.
  • The story is likely to affect their own work, so they should have an opportunity to comment before the story is finalised.

Acceptance criteria are a key element of a story, as they focus development on explicit, testable needs.They take the following form:

  1. Given <starting point, user action, system state or trigger>,
  2. When <user action/system input, etc.>,
  3. Then <verifiable effect or output>.
5Validate story quality.Iteration Lead.

Team.

User.

Finalised story.
  1. Check the story against basic criteria for a well-written story.
  2. If it fails to meet the criteria, rewrite it.
  3. If the iteration task plan is already in place, validate it against the Definition of Done.
 A widely used set of story quality requirements is the INVEST model:A story should be:

  • Independent. – i.e., self-contained and functionally independent of all other stories.
  • Negotiable. Until part of an iteration, User stories can be changed.
  • Valuable. Valuable to the user in its own right.
  • Estimable. Enough is known to estimate the story realistically.
  • Small. Small enough to deliver within the current iteration along with other stories.
  • Testable. Capable of being verified by the team within the iteration.

Issues and risks

What are the key concerns in making a success of this practice?

  1. For more on stories in general, click here.
  2. Historically Agile stories were thought of as specifically user stories. This may be too narrow a conception, and other kinds of story should also be included.
  3. The story format does not suit all user needs.
    • Where the real users of a system cannot speak for themselves.
    • In such circumstances, alternatives such as Feature-Driven Development (FDD) should be considered.
    • Once the backlog has been populated with agreed features, it can be assigned, managed and implemented in  the same way as a story-based backlog.
  4. Sometimes it isn’t realistic to elaborate needs during the development process:
    • Detailed technical or regulatory specifications aren’t well communicated by informal discussion.
    • Stories affecting multiple customer or user groups may need extensive agreement.
  5. Not all ‘stories’ are stories at all.
    • Statements like ‘Must support peak load of 15,000 concurrent users’ or ‘98% availability’ are constraints, not stories.
    • Being asked to clone an existing system, function or capability isn’t a story either. Ask what the story is which the copied item is supposed to support: exact copies rarely make much sense!
    • Such items need to be taken into account when evaluating stories or developing the system, and should be carefully recorded and analysed for their impact.
  6. Stories are not equivalent to formal requirements. If you are inclined to think that they are, click here.
  7. There is no standard way of including non-functional requirements in a story. For example, you could include them:
    • in the Acceptance Criteria.
    • in the story’s Definition of Done (especially if they are shared with other stories).
    • in tests.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?