Posted 12 months ago. Visible to the public. Repeats.

Project management best practices: The story tracker

In general, the tracker should always be the definitive source of truth of what needs to be done as part of a project. If you identify a task that needs to be done, you should create a story. If you learn something that contradicts an existing story, change it.

The tracker can contain two types of stories: Developer stories, and non-developer stories.

Non-developer stories

Non-developer stories should be clearly marked. They usually belong to the PM (or maybe people from the operations team). Those story can take all forms, could just be simple reminders etc.

This allows non-developers to work in the same tracker as developers, but show clearly which stories are meant for development, and which are not.

Developer stories

A developer story (if not in the icebox) always has to have a description, and should adhere to our preferred story format.

All the info that is necessary to accept a story should be directly in the description. Instead of adding a comment on "what is still left to do" etc, create a new story.

Stories are usually created in the icebox, where they are not considered ready for development. A story is never moved into the backlog unless a developer (usually the project lead) confirms it is sufficiently fleshed out and ready for work. By default, stories from the icebox should be moved into the back log as part of the daily stand-up, but there can be exceptions.

The inbox

Within the icebox, it is advisable to have a ^^ INBOX ^^ divider. Stories in the inbox are meant to be moved to the backlog (but maybe need further clarification, or the attention of other developers). Stories outside the inbox usually are "delayed indefinitely".

Growing Rails Applications in Practice
Check out our new e-book:
Learn to structure large Ruby on Rails codebases with the tools you already know and love.

Owner of this card:

Tobias Kraze
Last edit:
11 months ago
by Besprechungs-PC
About this deck:
We are makandra and do test-driven, agile Ruby on Rails software development.
License for source code
Posted by Tobias Kraze to makandra dev
This website uses cookies to improve usability and analyze traffic.
Accept or learn more