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:


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


  • 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


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


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


  • 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


Leave a Reply

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