Using Reviews to Scale Whose Work is Represented

Tracker has had the great fortune to grow up with our users. We began helping small startups and organizations learn to work in an agile way. Over the years, our users have seen great success and grown larger, which comes with excitement and challenges.

One of the biggest changes we see in scaling companies is the increased specialization of roles. We also know that for organizations large and small, but especially large, more people than just engineers and product managers often need to have eyes on a story before it can be released to production. Some of the most frequent examples are QA engineers, security testers, designers, legal teams, customer support specialists…and the list goes on.

We found that our users were painfully hacking this with labels, with a process that went something like this:

• Add a label called Needs QA
• Sam the Tester picks up the story; removes Needs QA, adds Sam Testing
• Sam completes work; removes Sam Testing, adds Sam QA Pass or Sam QA Fail

This causes a number of problems, like forgotten and duplicated labels, or stories released without all the necessary eyes getting a chance to see them. In short, this hack created low confidence that stories were ready for release if anyone other than a product manager or engineer needed to look at them.

To address this, we’ve elevated Reviews to a first-class feature in Tracker.

Tracker believes that software is a team sport: handoffs kill context and turn us into assembly line robots. We have specifically designed Reviews to be completed in parallel with each other and with other work, so getting value to users does not slow down.

We seeded the types of available reviews with a few options many teams already use: Test (QA), Design, Code, and Security. But we also know that every team will need different eyes on different stories. To create custom review types that work best for your team, go to Manage Review Types from the + add review dropdown and add the new review types your team needs.

A few best practices for using Reviews

Reviews can be added to a story at any time.

• Add a Test (QA) review to a story once the acceptance criteria is written for QA to review before an engineer starts coding.
• Add a Design review to a story once it is delivered to ensure it is pixel perfect before release.

Like owners of a story, reviews should float until they’re ready to be picked up, so that the first appropriate, available person can address them.

• Reviewers can also be added or changed at any time, so if there’s a single, specific person on the team who will complete the review, they can be assigned when the review is created, rather than when it’s started.

Once a reviewer picks up a review, this is the workflow we imagine:

• Reviewer should assign themselves to the review.
• Move review to “In review.”
• Complete review.
• Add comment about the review if needed.
• Move review to “Pass” or “Revise.”

If a review needs revision, the reviewer should reject the story if it must return to developers. The developer who redelivers the story should simultaneously set the review back to “Unstarted” to signal to the reviewer it is ready for them again.

Reviews will help all members of balanced agile teams better represent their work in Tracker. We are still iterating on this new feature, so please share your thoughts in the feedback module, a link to which will appear after adding a review. Learn more about Reviews by visiting the Help Center. We look forward to hearing how your team is using this new feature!