Pivotal tracker

We all understand that there is no universal project management system that would be suitable for all cases. The choice of the system entirely depends on your needs. If you do not need repositories, and for communication you have enough comments on the tickets, and you are working on a projector on “flexible” methodologies, then perhaps one of the best options would be - Pivotal Tracker .

The post is primarily intended for those who are not familiar with Pivotal Tracker, or those who consider it difficult and incomprehensible.

Interlude

"Pivotal Tracker is a story-based project planning tool."

Pivotal is designed for projects developed on "flexible" methodologies, is completely free and written in Ruby on Rails.
')
The key concept of the Pivotal system is “Velocity”. In this concept, I think, there will be opponents, defenders and ardent fans. I try to keep neutrality.

Velocity is the average point per iteration, it is calculated from recently completed iterations. In the settings of the project, you can set by how many iterations Velocity will be calculated.

Point is a relative measure of the “effort” required to close a ticket. For users previously not familiar with such terms, the concept may seem very vague, it can be perceived as the complexity of the ticket or the amount of work.

For example, in the weekly iteration Velocity is equal to 10. In this case, the sum of points in tickets in the current iteration should not exceed 10, otherwise they will begin to fall into backlog. If Velocity has exhausted all tickets and closed it, but it is possible to do some more tickets on this iteration, then you can simply return them from the backlog by clicking on one of the start tickets and it automatically drops into Current, even if Velocity is not enough .

Points can be awarded in one of the following types:

• Linear (0, 1, 2, 3)
• Powers of 2 (0, 1, 2, 4, 8)
• Fibonacci (0, 1, 2, 3, 5, 8)

Interface

Almost all the work on the project is reduced to work with the main page of the project. There are two main advantages to this:

• no more tedious page reloads;
• All work on the project can be assessed with one glance, and not run through the pages keeping everything in mind.

The main page contains stories, or in another ticket.

An example story: 'A shopping cart.'

I think this concept will especially appeal to BDD lovers. But in principle, stories can be viewed as tickets, because the concept of story is not applicable in practice everywhere.



As we see, there are four piles “Done”, “Current”, “Backlog”, “Icebox”. We can hide and show any of them at any time.



Icebox is where the ticket enters after creation, and is stored there until you start working on it, moving it to Current.

Current is a list of the current iteration (the length of the iteration is selected in weeks). If the tickets do not fit in the current iteration, they will automatically fall into the Backlog.

Backlog - if the number of Velocity (by default 10 for one week) is not enough for all tickets of the current iteration, then the remaining tickets fall into this pile.

Done is the stack where the closed tickets get after the current iteration is completed

Ticket can be moved between piles (all but Done). It is clear that we cannot put the start up ticket in the Icebox, or put it in the Backlog, then what Velocity is enough for in the current iteration (Current).

On the same page you can show columns with Releases, My Work, Charts, Project History, Charts, Labels (tags or compponents).

Stories (tickets)

Tickets can play the role of Feature, Bug, Chore, Release.

All these types can have the following fields:

• Labels (tags)
• Owner
• Description
• Attach file
• Comments

Feature is a feature. In addition to common fields, they may also have a points rating.

A bug is a bug, what can I say?

Chore is a ticket in which you need to implement the functionality that is necessary for the developer, but not viewed by the customer. It can be either refactoring, or testing, or anything else.

Release is just a ticket checkbox that serves to mark the place where the release should be made. In addition to common fields, there is a Deadline field, with a release date.

Feature and Bug have several states: Not yet started, Started, Finished, Delivered, Accepted, Rejected.

Release has only Not yet started, Accepted, and Chore has Not yet started, Started, Finished.

Ticket priorities are very simple to change, it is enough to simply transfer the ticket to a new drag & drop position.

Conclusion

I see no reason to fully describe the functionality of Pivotal Traker, the main thing I wanted to show is the approach used in this tracker, extremely convenient for “flexible” development, when you do not need to evaluate the iteration in hours, but rather estimate the approximate amount of work and complexity, and also an interface that I find very convenient. If I’ve done any of this, that’s good. I hope your time was not wasted.

Links: Getting Started , FAQ