What's the typical life cycle of a Tracker story?
2
people have this question
I have this question, too!
Tell me when someone answers.
The more people who ask this question, the more it gets noticed.
The more people who ask this question, the more it gets noticed.
The company marked this question as answered.
-
Inappropriate?In Tracker, a "story" is something that representing a concrete product feature, bug, or technical chore (such as code refactoring). Stories can be created by anyone who is a Member or Owner of your project.
New stories will initially appear in the Icebox, and will remain there until they're explicitly dragged into the Backlog (or "prioritized").
Prior to moving a story into the Backlog, it will typically be estimated by developers in "points", to indicate it's complexity relative to other stories. This is done by clicking on one of the blue bars. Once estimated, a Start button will appear to the right of the story name.
When a story is ready to be prioritized, someone playing the Customer role on your project (typically a product manager or team lead) will drag the story from the Icebox to an appropriate position in the Backlog, based on it's priority relative to other stories there. Subsequent iterations in the Backlog will immediately be re-planned by Tracker. The story will now be in the Not Yet Started state.
A developer will clicks the Start button to indicate work has begun on the story. If the story is unassigned, the developer will automatically become the story owner. Now, the story will be in the Started state, and the Start button becomes a Finish button. Note that starting a story automatically moves it into the current iteration if it wasn't already there, pushing unstarted stories into the backlog if necessary.
When a story is finished and code checked in, the developer clicks the Finish button to indicate it is ready to be delivered to a demo or QA environment for customer verification. The Finish button becomes a Deliver button and the story now waits for the developer or a release or QA engineer to deploy to that demo/QA environment. The story is now in the Finished state.
When the code for the story has been deployed to a demo or QA environment, the developer, release engineer, or QA engineer will click the Deliver button to indicate the story is now deployed and ready for a customer test-drive in the demo/QA environment. The Deliver button is replaced by the the Accept and Reject buttons. The story is now in the Delivered state.
The story requester or a product manager is usually the one to accept or reject the delivery of a story. Clicking the Accept button indicates that the story is has been verified, and the functionality is ready for production. The effort points for the story are added to the running count in the current iteration and the status update buttons disappear. The story is now in the Accepted state, and will automatically move to the Done panel when the current iteration ends.
If something doesn't look right, the story can be rejected, with a comment describing why. Rejected stories will show a 'Restart' button, allowing the developer of the story to make corrections based on the feedback.
Story state can be directly changed to any other using the pull-down menu in the detail view, although it is usually best to use the action buttons.
The company and 1 other person say
this answers the question
Loading Profile...


EMPLOYEE
EMPLOYEE