Reviewing Pivotal Tracker

To plan and track Observu features we are using Pivotal Tracker. If you recognize having a features list where half of the tasks has the highest priority, you will probably like the idea behind it: the tasks are in a completely ordered list. This enables to clearly think and communicate about what really needs to happen first. You can’t just move one thing forward without moving other stuff backwards: decisions need to be made.

Other critical ideas are an icebox with unscheduled features, the need to estimate a task before you can start on it and a planning based on actual output based on past progress.

By keeping features in the ‘icebox’  you can already write down your ideas, without them clouding up your vision about what is on your current critical path. That’s something hard to do in other systems, do you give it a low priority? But what if it is a really important aspect, but just not now?

Because Pivotal tracker displays your list of tasks over time based on your previous progress, it is immediately clear how you are doing.  At first, it may seem daunting that your milestones are much farther away than you initially guessed, but it makes obvious that there are only two ways to change that:  actually speeding up or reducing the tasks for that milestone. It all makes you take a much more realistic look on your project.
This is especially true because programmers tend to estimate tasks by the time it takes in idea conditions, without taking into account that such conditions do not come in abundance.

For example,  coding up a piece may have taken you four hours, the whole project is 10 times as big, so you should be finished in a week, right?  This thinking tends to neglect the time you’ve spend thinking about the task and the fact that not every day is as productive.
As Pivotal tracker expresses things as points done per iteration instead of hours spend, the estimates become much more realistic.

As with any service, things can’t be perfect. First of all, I miss the opportunity to add extra documentation. Although you can write a description and add attachments, the space is fairly limited.  I would love it if I could add an extra stage in the workflow that is: adding specification/documentation.  Although maybe I should just use the icebox for the tasks without proper specification and only schedule them once they have.

Another thing is that having a completely ordered list makes you feel obliged to start on the first task, but if that one is particularly hard or daunting it may hurt productivity.  This is purely in my mind, because there is no problem at all starting on other tasks.

Even after a few months of use I am still in doubt whether I miss the lack of hierarchy.  The feeling I need a hierarchy probably has to do with the fact that I sometimes tend to create to big tasks, that keep dangling in the ‘current’ box.  Working a full day and than not being able to cross anything off is bad for motivation. So I do often feel like I need to split up bigger tasks, but than, why not just reduce the scope a bit and add a secondary task for the rest of the feature? Doing so will probably be better from a planning point of view as well, because it makes much more explicit that the task was actually bigger than anticipated and you need to allot some extra time to it.

From a more practical point of view, the whole thing does breathe that it is intended for teams. As I am mostly the only dedicated developer on this project, I do feel that it works better if you increase the size of iterations up to four weeks.

Taking everything into account the idea of having a single ordered list of features instead of just a bunch with priorities is amazing. It gives you so much more information and forces you to make decisions on what really needs to happen and what needs to happen first.