As already tweeted, we have a winner in the Pivotal Tracker GoGaRuCo Haiku contest. It was a tough choice, with lots of awesome submissions. The ultimate call went to Sarah Gray, with her entry below:
Bloom and iterate.
Each story a fragment of
the pivotal whole.
Below are the three runners-up:
Icebox, Backlog, Done
Righteous Fall stories sorted
Tracker guiding flow
Don Smith
Tracker has arrived,
transparency is blooming,
the team uniting.
Gustin Prudner
heisenberg was wrong
I know both where I am and
my velocity
Dav Yaginuma
The runners-up will be receiving a Pivotal Tracker mug. Thanks to everyone who participated!
A frequent feature request for Pivotal Tracker is support for parallel tracks of development for multiple pairs of developers (you are pair programming, right?) It's true that Tracker does not fully support parallel tracks within the same Project, but you can get most of the way there by doing what we do on many Pivotal Labs projects: use labels to identify multiple tracks of development. With labels, you can easily visualize and manage parallel development tracks while keeping your team's work in one Pivotal Tracker Project.
Jeff Sutherland, one of the creators of Scrum, has just posted a new blog entry in his Scrum Log: Pivotal Tracker: Now with a Burndown Chart!
I first met Jeff when we were both presenting on Agile process to a forum of OpenView Venture Partners portfolio companies, and have been a big fan of all he has to say about the adoption and effectiveness of agile practices in the wild.
Many thanks to Jeff for his help to make Tracker a better tool for scrum. We'll keep working with him to make sure Tracker is the best scrum tool it can be.
We have a winner in the Pivotal Tracker GoRuCo Haiku Contest.
Collin Miller submitted the winning entry:
Rivers of Action
Clearly Sculpt a Way Forward
My Path is Now Clear
We thank everyone for participating. There were a number of great entries, but this piece really stood out.
Collin, come on down tomorrow and say hi. I'll be there all day enjoying the conference with some other folks from Pivotal Labs and demoing Pivotal Tracker for anyone who doesn't know it already. Congratulations on your win!
At Pivotal Labs, our clients, customers, and developers love Pivotal Tracker; after all, we wrote it and selfishly kept it to ourselves for 2 years! With that much history, some of our Tracker projects have built up thousands of stories, and keeping these stories organized is a challenge. Luckily, we designed Tracker with a simple yet powerful organizational tool: Labels. Here are some labeling patterns we find useful.
On Wednesday night we hosted our first San Francisco Tracker Users Group (SF.TUG)
It was a great opportunity to meet more of our users, and hear directly from them about how they're using the product, and share with them some of the philosophy behind it.
We're excited by your enthusiasm and we will definitely make the TUG a regular event here in San Francisco, and we are planning to start one in our New York City offices soon. Please visit the Meetup group to join the discussion, and for more information and the schedule for future meetups.
On April 29, 2009 Pivotal Labs hosted the inaugural San Francisco Pivotal Tracker User's Group. It was a great success! As an avid Pivotal Tracker user (and sometimes developer) for over 3 years I am very interested in making Tracker a better product and teaching others how to use Tracker to improve their organization.
Here are a few thoughts I took away from the meeting, and a few tips and tricks.
I came across an interesting post on Overcoming Bias today about the Planning Fallacy. In short, the evidence shows that individual predictions generally occur in a rosy inaccurate world where everything goes according to plan, even when interruptions and setbacks are inevitable:
Buehler et. al. (1995) asked their students for estimates of when they (the students) thought they would complete their personal academic projects. Specifically, the researchers asked for estimated times by which the students thought it was 50%, 75%, and 99% probable their personal projects would be done. Would you care to guess how many students finished on or before their estimated 50%, 75%, and 99% probability levels?
- 13% of subjects finished their project by the time they had assigned a 50% probability level;
- 19% finished by the time assigned a 75% probability level;
- and only 45% (less than half!) finished by the time of their 99% probability level.
As Buehler et. al. (2002) wrote, "The results for the 99% probability level are especially striking: Even when asked to make a highly conservative forecast, a prediction that they felt virtually certain that they would fulfill, students' confidence in their time estimates far exceeded their accomplishments."
But it seems one can overcome this bias towards optimism by getting an "outside view" on the problem as it relates to the timelines on previous similar projects:
Buehler et. al. (2002), found that Japanese students expected to finish their essays 10 days before deadline. They actually finished 1 day before deadline. Asked when they had previously completed similar tasks, they responded, "1 day before deadline." This is the power of the outside view over the inside view.
So there is a fairly reliable way to fix the planning fallacy, if you're doing something broadly similar to a reference class of previous projects. Just ask how long similar projects have taken in the past, without considering any of the special properties of this project. Better yet, ask an experienced outsider how long similar projects have taken.
Pivotal Tracker, unlike other project management software, is built on exactly this idea of the outside view, via points and emergent iterations:
Tracker calculates future iterations based on historical performance. Focus on prioritizing and completing your stories; let Tracker take care of planning future iterations, based on actual progress.
It's gratifying to see that the emergent iterations are not just easier for the user, as there's no need to manually specify them - they're also more likely to be accurate, as they're based on an external view of your own progress. Yet another reason to look to Tracker for your project management needs.
As a developer of web apps, I'm inevitably running 3 or 4 browsers, each with 10 tabs open containing my application under development, Google searches, gotapi (pronounced "got a pie?" of course!), design wireframes, and all kinds of other very important stuff. And in one of those tabs, somewhere, is Pivotal Tracker. Browsers and tabs are great, but sometimes you just want an Application -- notice the capital "A."
Fluid to the rescue! Fluid lets you create Site Specific Browsers, which "provide a great solution for your WebApp woes." In a nutshell, Fluid makes a custom WebKit browser that, when launched, opens just the site you configured it to open, such as Gmail, Pandora, or even Pivotal Tracker. I love that I can maximize the Pivotal Tracker app and boost the font 3 or 4 levels, filling a screen with Tracker goodness without the clutter or navigation buttons, bookmark bars, or tabs. And where is Tracker? Just command-tab!
Here's how to create a Fluid application for Pivotal Tracker.
- Download and install Fluid
- Download the Fluid Icon for Pivotal Tracker
- Launch Fluid
- Enter the following:
- URL: http://www.pivotaltracker.com
- Name: Pivotal Tracker
- Location: pick one!
- Icon: pick 'Other...' then find the tracker icon you downloaded earlier
- Click Create, then launch it!
Once launched, open the Pivotal Tracker preferences and change the Window Style to "HUD (Black)" under Appearance Preferences Why? Because it looks cool.
Update
Here is the Fluid icon, upon request.
Interesting Things
Pivotal Tracker tip: as the Holiday Season approaches, you can edit your Team Strength to account for vacationing team members. For example, if you are missing 1 out of a team of 4 next week, set next week's Team Strength to 75%
Rescuing inside a transaction: ActiveRecord relies on catching a Rollback error in order to perform transaction rollbacks. If you are performing a
begin..rescueblock within a transaction, make sure you either (a) specify the Exception or Errors you want to catch, or (b) re-raise the Rollback error if caught.Bring it! The Pivot Pong Tournament of Champions is on! Games will be played on the Pivotal breakfast tables/ping pong table.
Ask for Help
"What is the life-cycle of test fixtures when using transactional fixtures?"
- The testing framework clears the database of all data within tables that have fixtures files defined.
- A test/spec file is loaded and all fixtures declared within it (or all if
fixtures :allis declared) are loaded into the database. - A transaction is started.
- The test/spec runs.
- The transaction is rolled-back.
- Repeat!