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