Here are some hints on how to use tracker effectively gathered from my experience using tracker and coaching agile teams. Tracker is a lightweight project management tool for agile project planning. It is designed to help you stay focused on getting things done and keep in touch with team priorities.
What is it useful for?
Tracker answers the question “What should I work on next?” for each member of the team. It also gives estimates for when things will be completed based on how much work the team has completed in the past.
Tracker is lightweight, it is meant to be used in combination with a short daily team meeting (called a Scrum or Standup). This combination of a lightweight tool and strong team communication works together to help the team respond to the new information that always emerges in complex projects and deliver on commitments.
Tracker was designed by Pivotal Labs (leaders in the agile community) specifically for software development using the Extreme Programming methodology. But tracker has turned out to be so useful that participants in other kinds of projects have gotten excited about it.
Keep in mind that, tracker is event based and so processes should be documented elsewhere (e.g. make the coffee every morning at 7:30am). Tracker is not specifically designed to be a bug tracking system, version repository browser, help desk tool, etc. It’s purpose is primarily to effectively plan software projects. That said integrations with these tools is possible. You can learn more about integrations here.
Ok, what is agile?
Agile is a family of project management practices that share principles of team communication, responsiveness to changing requirements, early delivery etc.
In 2001 some highly regarded leaders in the software industry came together and outlined the core principles of agile and coined the name. Even though the software development practices they advocated have been evolving since at least the seventies, the presentation and prioritization of their principles was new. Agile has had a large impact in the project management community. Here are the shared principles of agile processes (aka. the Agile Manifesto):
Despite sharing the core principles in the manifesto there are numerous agile methodologies (XP, Scrum, Lean, Up, Crystal, etc.). If you want to learn more about agile in general there are some great books to get you started.
For project managers you may want to explore “Agile & Iterative Development” by Craig Larman. For software developers “Extreme Programming” by Kent Beck is a classic.
Are there some extensive getting started materials for Tracker? Besides reading this guide which has some commonly asked questions. You will want to watch the videos on the tracker site here: http://www.pivotaltracker.com/help/gettingstarted
What is a story?
In agile, a story is a description of a task. In Tracker stories come in 3 flavors with 3 different icons: a feature (star), a bug (ladybug), a chore (the cog).
How should I write a story?
Story writing seems simple but it’s an art. A good story satisfies a number of requirements like a haiku.
Some principles of good story writing are:
- A story should be written in a way that is understandable by all members of the team (technical, non-technical, managerial, local, remote, newbie, etc).
- A story should be written so that you can answer the question “is this done?” with yes or no.
- A story should describe a benefit to the system user or the team
One way to write the story is to use this structure:
Examples: A sales rep should be able to login using their email address An anonymous user should not be able to access the profit reports page
What is a point?
A point is a measure of work agreed upon by the team. Whenever possible the work should be a measure of complexity rather than time.
If points are used for chores these may initially require that a time measure is used (2 hours for example). But there is variance in how long work will take different individuals. Because of this, task complexity is more appropriate since a story may be completed by any team member.
It is important that the team arrive at a shared understanding of point measures. Also, the estimation of a specific story should be done by a person familiar with the complexity of the work. One strategy to arrive at team agreement is to come up with a general reference chart for story complexity points.
With the points accurately assigned by someone knowledgeable about the story’s complexity, a manager has an accurate estimate of what the cost of the story is. The manager can then decide how to prioritize the story given business needs, deadlines, and the point costs of other stories.
Why use points?
Estimation is hard particularly in complex software development with changing libraries, upgrades, new technology, third party integrations, etc. The software industry has historically underestimated the time it will take to get things done.
Points are a way to base estimations of future progress empirically on past progress. By using a non-hourly measure of work, expectations of future work can be adjust based on the actual record of what has been accomplished.
What is velocity?
Velocity is the average number of points the team has delivered over the past few iterations. By default 3 iterations is used.
How big should my story be?
A gigantic story is called an epic. Sometimes these are useful as placeholders in estimating releases. But they should be broken down into smaller tasks before they are worked on. Medium size stories should be broken into smaller stories when possible for better estimation.
It is possible to have check lists inside of stories. Be careful with check lists. You can frequently throw off your estimates and reduce your planning flexibility by using check lists. Whenever possible break checklists into smaller stories that can be separately estimated and re-prioritized.
How can I keep track of multiple simultaneous projects? You should have just one active project per team. The most important question is “what should I do next?” and to do this effectively you need one priority list.
To track more than one project, you can use labels. When you view the details of a story, there is a drop down list where you can define and assign labels. By clicking on a label you can bring up a list of stories with that label and their point total. There is also a list of all labels available from View > Labels & Searches.
What is the difference between a feature bug and a chore?
Here are the typical definitions of story types. You may need to adapt them to your own team particularly if your team does more than just deliver software.
A feature represents the development of customer facing software value. A chore is work that is not a feature: testing, planning, risk management, conversations, content, etc. A bug is anything that should work but doesn’t.
Note: an area of debate is whether data migration is a chore or a feature.
By default tracker does not have points assigned to chores and bugs. This is because the focus of a software team is to deliver customer facing software value. Anything else is a defect or a distraction. Point estimation is for working software and if there are bugs then the estimate was wrong and the velocity should drop appropriately. If there are lots of chores this is a sign that the team may have distractions or has issues in design that are forcing re-factoring. These measures can be summarized by velocity and give team members insight into the true health of the project.
Having points assigned to chores and bugs may be desirable to achieve more accurate estimates, particularly on teams that have non-software development commitments. However, be aware that turning on point estimation for bugs and chores can obscure trackers focus on customer facing value.
How can I find stories assigned to me?
Click on anyone’s initials in a tracker story to see stories assigned to them. Or, click on View > My Work.
What states can a feature have?
Features can be unstarted, started, delivered, approved, or rejected. Stories and bugs can be unstarted, started, or completed.
Who should adjust a stories state?
- Anyone on the team can create an unscheduled story.
- Inclusion in the current iteration or backlog should be by the project manager – they understand the business needs of the company.
- Priority should also be adjusted by the project manager
- Estimation should be completed by the person doing the work.
- When the work is begun the person doing the work should click start
- When the work can be verified by the project manager it should be marked as delivered.
- Final approval or rejection should be done by the project manager.
For chores and bugs:
- Anyone on the team can create one
- If you are using points then you should defer to the project manager for priority. Some software development teams that do not use points allow developers to create schedule and prioritize chores. This is because developers arguably have more knowledge of required code maintenance chores than managers, and these low level code decisions are factored in to the velocity.
- The person doing the work clicks start and finish
What releases are planned? Are they on schedule?
You can see a list of releases and whether they are on schedule (blue) or slipping (red) by selecting View > Releases. And of course, blue and red release markers appear in the current iteration and backlog.
A pragmatic note: To accurately track if releases are late be sure that the due date falls before the end of the tracker iteration you want it completed in. For example, the stories leading up to a Monday launch deadline should have a due date that falls within the previous iteration (assuming the end of your iterations is Friday or Sunday). If this is not the case it will not appear red in tracker even if a few days late but still inside of the iteration containing the due date.
The reason for this is tracker assumes that iterations are one week long. Continuously releasing teams can be thrown off by this.
Where are my charts?
The charts are found under your projects View > Charts option.
The burn down chart is the primary way of tracking progress towards long term releases in agile projects. It shows the number of points needed to be completed by the release, charted against the number of points that have been released. It also includes a projected completion date.
Burn down charts are a useful tool. You can increase the accuracy of the chart by making sure that stories required for the release are in tracker and are estimated.
Pragmatically speaking, projects frequently increase in scope. So, leave yourself room for some scope creep in your deadline. If your projected date is beyond the deadline:
- believe that you have a serious issue
- hold an immediate planning meeting and examine all stories leading up to the deadline
- move all features that are not essential to the release to after the deadline
- renegotiate requirements if necessary
- be vigilant about not accepting new change requests
There are some other charts in tracker as well.
Here is the FAQ info on charts.
Are there other reports?
Most reporting is done through charts or by looking at the backlog and release dates. This is usually fine for a team, but can be limiting for managers in larger organizations.
There are additional reports in the reports section. For instance, you can observe the project point progress for the last 30-90 days here: Reports > Points Breakdown
Some faq info on these reports is here.
In some cases you may wish to use the csv export functionality in the actions menu. Additionally, you may wish to integrate with other products or use the API to develop reporting functionality specific to your needs.
Can I get raw data from Tracker to generate reports or create my own integrations?
Yes. Have a look at the API section
Can I integrate tracker with a bug tracking or help desk system?
Yes, there is information on this here
Notably you can integrate with Zendesk, Lighthouse, Jira, Twitter, GetSatisfaction, and Campfire. You can use the generic integration API for custom integration.
Are there shortcut keys for tracker?
Type “?” and it will bring up a list of shortcut keys.