Skip to content →

The Life of a Story

A colleague of mine Derrick Malone put together some instructions for how to manage User Stories during our development cycles. This was published on our internal wiki, but I thought that it was worth publishing to the wider audience due to its excellent, concise delivery. So with Derrick’s permission here it is:

Discovery

  • Business rep gathers ideas from around the business (Tesco in this case) and raises with BA
  • BA captures ideas in Pivotal Tracker Icebox, providing what info he can and also raising obvious questions in ‘Descriptions’
  • Tasks can be used here to describe next steps to be undertaken to aid understanding
  • BA and business work together to understand who the story benefits, what is to be developed and why a postive outcome is to be expected.

Planning

  • When it is better understood the initial story is split into sensibly sized stories, each of which can be released independently to deliver value.
  • The stories are ordered sensibly by the BA and prioritised by the business to deliver most value (and learning) first
  • All dependencies (eg designs, platform work, unanswered questions) are identified and captured in the user stories
  • Stories are presented to the development team for their input and estimation.
  • story is estimated if it is suffiently understood by the dev team
  • There are four acceptable estimates:
    0 – no dev work required
    1 – a small amount of dev work required
    2 – a medium amount of dev work required
    3 – a large amount of dev work required
  • story should take no longer than a week to complete. If developers think it it exceeds a week the story should be broken up into smaller stories that each delivery value.
  • When fully understood and estimated a story can be prioritised into the Pivotal Tracker Backlog

Delivery

  • When available a developer picks up the highest priority story available (the story nearest the top of the Current column).
  • The developer should review the acceptance criteria, hit the Start button in Pivotal Tracker and discuss the story with the BA and a tester.
  • In the Tasks field the developer should document the steps he will pursue to meet the acceptance criteria and deliver the user story.
  • When the developer has completed the work necessary to satisfy the acceptance crieria he demonstrates the feature to both a tester and the BA.
  • If all agree that the story can now be passed on to a tester the developer hits Finish on the story and moves on to a new story.
  • A tester takes the highest priority story marked with ‘Deliver’.
  • The tester hits the Deliver button to own the story.
  • When a tester is satisfied that the story is done he should demo to the Business and/or BA and, if they agree, he can hit ‘Accept’
  • If a tester finds problems with the story meeting the acceptance critera – or other problems with the story implemenation – he raises issues in the Activity field and hits the Reject button.
  • This changes the status of the story back to ‘Restart’
  • A developer should pick up the highest un-assigned story in a Restart state.
  • All Accepted stories are ready to be released and, ideally, should be released at the earliest opportunity.

Review

  • Stories should be reviewed against their stated goals after they have been released (this yet to be fully defined).

Iterate

  • Improvements should be developed from learnings gathered during planning, development and review.

This process is a little specific as we use the excellent Pivotal Tracker as our backlog management tool, however the process could be delivered using any Agile project management tool.

Published in Uncategorized

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *