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