Tracker’s lightweight workflow supports teams as they deliver value to the business at a sustainable pace. Let’s walk through a simple example of Tracker’s feature story workflow.
- Write stories. The customer, project or product manager (PM), or product owner (PO) adds new feature stories. This might be done in an activity with other team members, such as story mapping, specification workshops, or an iteration planning meeting (IPM). Mock-ups, assets, or other examples may be attached to stories and/or epics. Stories are in the unscheduled state if they are added to the Icebox, are unestimated, or if they have points to estimate in place of an action button.
- Prioritize stories. The customer/PM/PO prioritizes stories in Backlog. Stories are then in the unstarted state, and remain unestimated.
- Estimate stories. In an IPM, the team discusses each story to gain shared understanding, adds extra information as needed (such as acceptance criteria), and collectively estimates each story. Estimated stories have a Start button.
- Start stories. When they’re ready, a developer or developer pair clicks Start on the next unstarted, estimated story in the current iteration. If the story is a feature that has yet to be estimated, they’ll be prompted to assign a point value prior to continuing. The story is now in the started state, with a Finish button and, unless preassigned, the person who clicked Start becomes a story owner. The developer(s) collaborate with other team members (such as the customer/PM/PO, designers, and testers) to perform the testing and coding activities to build the feature increment represented by the story.
- Finish and deliver stories. When coding and testing activities for the story have been completed, and the automated tests for it have all passed, the developer(s) click the Finish button (or possibly their commit message does this via Tracker’s SCM integration. Now the Deliver button is available.
- Test stories. After the CI build for the newly committed code has passed, the code is deployed to appropriate test environments, and stories are marked as delivered by a team member or automated deploy process. Now the green Accept and red Reject buttons are visible.
- Accept or reject stories. The customer/PM/PO, possibly in collaboration with testers, designers, and other team members, verifies whether acceptance criteria have been met, and accepts or rejects the story, completing the feedback loop. The accepted story turns green and moves to the top of the current iteration.
- Stories move to the Done panel. At the end of the iteration, accepted stories move to the Done panel.
If a delivered story needs additional work, the customer/PM/PO (or another team member, such as a tester or designer) clicks the Reject button. When you click the Reject button in a collapsed story, you’ll be prompted to enter a comment describing what needs to be revisited.
If you click Reject in an expanded story, you can add a comment describing what needs to change at the end of the story. By default, the story owner(s) will receive a notification about the rejection, though they can configure the notifications they receive.
Various factors that stall a story’s workflow can be highlighted using labels such as “needs design,” or “needs discussion.” You can also explicitly call out stories that are blocking other stories using Tracker’s blocking feature.
You can label all stories that are planned for a specific release, or that are related in some other way, to help clarify what’s happening in your project. If you decide not to do a particular story, and want to preserve the reason why rather than delete the story, you can use a label like “as designed” and accept it.
You can take steps to keep your team’s particular workflow visible. See Getting More out of Tracker > Tracker’s workflow for more.
Bugs
Bugs have a similar workflow as feature stories. They may be tagged with labels relating them to a particular release, feature area, or epic.
The customer/PM/PO (or other team member, such as a tester) prioritizes them. A developer or pair marks the bug started when they start working on appropriate automated regression tests and code fixes for it. The bug is marked finished when coding and testing activities are completed and deployed to an appropriate test environment. A tester, customer/PM/PO, customer support representative, or other team member verifies and accepts or rejects the story.
If you’re testing a delivered feature story and find issues related to that story, the most common process is to reject the story and record those issues in the story’s comments. However, sometimes it makes more sense to create a separate bug story and link to that story from the feature story. For example, the issue might be minor and not worth holding up a release, or it may be related to multiple feature stories that would be better dealt with separately.
Tracker doesn’t have all the features you might expect of a defect tracking system, such as bug priorities and severities (a bug’s position in the Backlog shows those; the more important it is to fix, the higher it should be in the list of stories). However, having clear overall priorities and making bugs visible in context with your feature stories can more than compensate. You can also find out more about Tracker’s integrations with external defect solutions as well as third-party solutions.