Sunday, June 2, 2013

Agile Project Development Best Practices with Pivotal Tracker.

Pivotal Tracker and Project Management

I've been through quite a few live updates recently, and haven't dropped in with any posts for awhile, but I hope to get some updates soon.  I'm still working on the book, and maybe it will even be out before the technology described in it becomes obsolete.  That's a story for another day.

So I'm just about done with the 30 day free trial of Pivotal Tracker and I thought I'd share some of my opinions an insights into getting the best use out of this project management/issue tracking tool.  I'll start by saying that this tool might not be for everyone.  If your still stuck in the old MS project days of Gantt charts and project items that take two weeks or more, then this might be a steep transition.  You have to think in smaller pieces to get a more realistic picture of what's actually going on, and how much work a given team of people can accomplish over the course of a week, month, or quarter.


The first thing you must decide, when using Pivotal Tracker, is how are you going to assign points.  You have multiple ways that points can be assigned, the default is 1, 2 or 3 points for small, medium and large.  The idea being that you decouple the number of hours that are associated with a given task, and the people doing the work can scope projects without worrying about nit-picking over hours.  Being as little old school, I prefer to have some linkage to hours, so I use the Fibonacci numbers 0,1,3,5 and 8.  I figure a point at roughly two hours, and if a task will take more than 16 hours, it probably needs to be split into multiple tasks, or stories.


The overall goal of a good project manager is given X amount of work and Y amount of resources how long will it take to get X done?  In pivotal this is accomplished with Velocity.  Velocity is generated by averaging the number of points the Team/Project has completed over the last 3 weeks.  Pivotal Tracker assumes that the team will be consistent, taking into account strength in a given week and it will show what can be accomplished by that team week by week.


The idea behind a story is that it is a task that can be started and completed within the same week.  The key here is to keep the stories small.  Stories can have sub-tasks, but be careful of putting too much in a story.  Being consistent in sizing stories will help in getting to the goal of figuring out what, can realistically be accomplished by when.

Story Types

There are 4 different types of stories.  Bugs, Features, Chores, and Releases.  In the default configuration, only the points in Features count towards velocity.  The idea being that it is features that drive the product forward and bug fixes and chores are overhead.  Releases are milestones that show up in the overall schedule and do not have points associated with them.  Releases are the only types of stories that can have dates associated with them.  A release will show up in Red when there are too many stories that have to be finished (are higher in the list than) the Release story.  I use Pivotal in more of a support environment so fixing bugs and chores are considered moving the product forward.  Allowing points on all story types can be changed in the project settings.


If you have multiple stories and want to track them from a higher level, you can create what is called an "Epic".  Epic's give you a way to group multiple stories together into a higher level project.  An epic is like a tag for grouping, but additional reporting features are available when stories are linked together with an Epic.

Project = Team

This is probably one of the most important things I discovered about using Pivotal Tracker.  I didn't see the ability to see a roll-up of Stories and Epics across multiple Projects.  For usability, tracking purposes, reporting and overall sanity, Project should be synonymous with Team.  If you assign your people to tasks across multiple projects, you won't be able to use the milestone scheduling features.

Current, Backlock and Icebox

When work is started, by clicking the "Start" button in a story, it's moved over to the "Current" column.  I used back-log for stories that have been estimated and prioritized.  Things that need to be done, but haven't been prioritized are put into the Icebox.  Priority can be adjusted by clicking and dragging items.

3rd Party Applications

I like to use Eclipse and there is a Mylyn - Pivotal Plugin for Eclipse to allow integration with Pivotal Tracking and Eclipse Team .  There are also quite a few third party programs that allow tracking and reporting on the Web, and a variety of mobile devices.

No comments: