Why we like Pivotal Tracker
The Kudos Agile/Scrum/Task tool of choice is Pivotal Tracker. Quite a few of the team had worked with other tools, such as Jira in the past. Whilst being extremely configurable our experiences with Jira all sounded very familiar: it became too complicated, there were debates over the workflow and it became a full time job managing it. Pivotal Tracker takes a different approach, it provides opinionated simplicity, where configuration is at the minimum. Here are some of the key features we like.
Pre-Defined Workflow
You can’t change the workflow, the states of tickets are Unstarted, Started, Finished, Delivered, Rejected and Accepted. And that’s it. We’ve found that to be perfectly good for tracking our tasks and we don’t end up with debates about how to configure or tweak the workflow.
Pre-Defined Story Types
Stories can be either Features, Bugs or Chores, where features add customer value, bugs are unintended behaviour and chores are necessary work with no obvious value to the customer. This simplicity once again works well for us, without any need to think about what types to create for tickets. We still have the debate about what is a chore or what is a feature from time to time, it’s not very black and white at times, with the user value being not immediately obvious but the task clearly a feature. We also try and balance the sprints with a given percentage of bugs and chores, fixing the priority bugs and using the chores to progress our long running engineering roadmap. We also use Epics to group the stories and have found that this helps our reporting against the product and engineering roadmap, giving us estimated delivery dates.
Simple Velocity Tracking
In Pivotal Tracker features are estimated with story points, we use the Fibonacci scale. The expectation to estimate in points is hard baked into Pivotal Tracker with the UI making it easy to set the points by story and to see the points. From completed sprints the team velocity is calculated, the default is an average over the last four sprints, which we’ve found works well. As a capacity tracking tool the calculated velocity has been a success for us, allowing us to give pretty good estimates of when we think features will be ready for release. What’s also interesting is the volatility of the velocity is calculated, sometimes we have sprints where we deliver lots of features, maybe because they’re all one point stories. This volatility can hinder capacity planning however, so we keep an eye on that, with the four week average usually being enough to smooth things out.
Backlog Chunking Into Sprints
Hand in hand with the velocity calculation is the automated sprint planning. Pivotal Tracker will chunk your backlog up into sprints given the current velocity. Each sprint can have a different team strength. This means that as soon as you drag stories into the backlog you can easily see how many sprints it will take to finish those features. This is the killer feature of Pivotal Tracker and has saved a lot of time debating how much we can fit into each sprint.
Pre-Defined Key Analytics
The default set of analytics provide exactly what we need to track our progress. It’s refreshing to have no configuration, just a couple of clicks and the information that we need in order to continuously improve how we work.
If you like what you read and think you could contribute to our team at Kudos then take a look at our careers page to see what roles we currently have open.
