When you’re bogged down working on your day-to-day chores and features, it can be tough to stay focused on the broader goal of smooth agile development. And while we don’t pretend that we have all the solutions, Tracker is, after all, designed to facilitate precisely that goal. Luckily, the time we’ve spent getting deep down and dirty with Tracker has allowed us to suss out the better agile practices from the. . .less better ones.
Here, then, are what we consider some leading practices for getting the most juice from the Tracker fruit, and for agile success more broadly.
Language is fluid and subject to interpretation, so try not to use a Tracker story as a stand in for a conversation. Consider doing a design walkthrough of a story or project with support and testers, so they can help with different perspectives on usage and customer requests. Use techniques such as story mapping and example mapping to get a shared understanding of features and stories. You can add artifacts from these discussions, such as a photo of the whiteboard, to your Tracker story as a reminder.
Are your story comments stacking up? Get people together briefly to go over the issues, then update the story with the key points. Discussing issues in person can minimize misunderstandings that can too easily become a distraction or time suck.
Whenever possible, customers and the delivery team should write stories together, because a story is both a customer business value and a deliverable. In this way, everyone’s interests and viewpoints can be shared and aligned.
Conduct a regular iteration planning meeting so the team can review and estimate upcoming stories, as well as understand the value provided by each story. Develop estimates as a group, so everyone can be heard. To make the process lighter, you could play an estimation game. We do not suggest Settlers of Catan. Instead, try something more like Rock, Paper, Scissors. To estimate a given story, have each team member toss out fingers—in line with the estimation scale they’ve chosen—to indicate their suggestion for story complexity. Did everyone estimate the same? Great! If not, begin a discussion and estimate the story together.
Create stories that are incremental and focused on the perspective of the user. So if you need to repair a brick wall, try to focus on the user’s interaction with a specific aspect of the wall, not the entire wall itself. The story, “Wall should be in good shape,” would be more useful as, “Passer-by should not see visible cracks in wall.” In general, a good guide is to keep stories small enough so that they can be completed in two or three days, including all testing.
At the same time, some stories will be grander in scope or more complicated despite your best intentions. You should still try to minimize this and reserve the practice only for stories of unclear or enormous scope, and then break them down. Otherwise, an estimate of 8 (based on the Fibonacci scale) is a cry for help. As a developer, you should ask for clarification and look for seams where the story can be broken down into multiple stories. Tip: use the clone story feature to reproduce it and break it into smaller bite-sized stories.
Steering the ship while simultaneously fixing a leak is a challenge, to say the least. To that end, you should have a Tracker Czar, who shouldn’t also be coding in the project they own. Owning a project is a lot of responsibility, but it makes a huge difference.
While it’s true that anyone can create stories and put them in the Icebox, only the customer (or a PM acting on behalf of the customer) should prioritize them. As the business owner, part of a customer’s decision-making process is to decide which features have priority over others. In other words, the customer should be making the hard choices.
Turning chores into features reframes them as items of direct and verifiable value to both the end user and project goals. This could simply be a matter of rephrasing the story, or arguing more strenuously for its business value.
Never restart an accepted story; instead, make a new story or bug. It’s cleaner, you can keep new information more focused, and it doesn’t detract from the work that’s already been done. You can always paste in the URL to the original story for context.
Rejecting a story with both tact and clarity can be challenging, but there are some strategies to make it go more smoothly. If you’re not onboard with a given feature or story, prefix your comment with “reject:”—it’s easier to scan and figure out which comment is related to the rejection.
After all, there could be more here than meets the eye. Again, have a conversation. Reassess what’s missing and make a new story; don’t just reject it without knowing all the details.
We encourage our product managers to provide specific acceptance criteria in the story descriptions, and testers will often add tasks to stories during an IPM or Design Meeting to identify potential issues to dive deeper on during testing. Good developers will take those testing notes into account while developing to reduce the number of rejection cycles for stories.
Location, location, location—it’s of paramount importance. Move a rejected story below currently started stories, adjacent to unstarted stories at the top of the Backlog. When developers look to see the next story to work on, they’ll see the rejected story as the next one to pick up.
Even if there is no verifiably universal way to use Pivotal Tracker for Agile development, and though it can accommodate a variety of approaches, time and experience have proven to us that some practices lead to better results. We hope these tips will help you use the app as efficiently and smartly as possible.
And as always, we’d love your comments. Email us your feedback, or respond in the comments below.
Category: Productivity
