Pivotal Tracker is a web-based task management system used by Xtreme Labs engineers as part of our agile development process. This blog gives an example of a common situation where Pivotal Tracker can help overcome project roadblocks.
The Problem
Ever been on a project where the client is in the process of building their server API and you need to coordinate these dependencies with your development? Sure, you can work around it temporarily by using stubs and/or fixtures, but sooner or later, you will be waiting on doing the actual integration. We need a way to clearly communicate our requirements for the client’s API, and to show them what we need to resolve these dependencies. Furthermore, we want to be able to prioritize these tasks as development moves forward.
How Tracker Can Help
Something that I’ve found to work in several projects I’ve been on is to create a project in Pivotal Tracker to help manage the API development. This is used in parallel with the main Tracker project. With the API Tracker, your role and the client’s role are reversed. We create and prioritize API tasks (stories) that the client needs to complete. The client keeps us in the loop with regards to what’s being worked on by starting, finishing, and delivering stories. The stories in the API Tracker should mirror the blocked stories in the Project Tracker. In our own Project Tracker, stories that are blocked on API work should include a link to the API Tracker story that needs to be completed before we can work on the blocked story. We can expose dependencies in development related to API development this way. This makes it clear to the client what’s blocking our progress, and exactly what they need to do in order to unblock our development.
Stories in the API Tracker often require further discussion. I’ve found it useful to keep a record of discussions and design decisions regarding the story in the comments section of each story. At times, the discussion can take place directly as comments in the story. Design decisions and discussions that took place outside of Tracker should also be recorded as a comment in the story. This way, we’re able to clearly prioritize API development tasks for the client.
Pros
- Leverages existing familiarity with Tracker, and expands on that familiarity for both ourselves and the client, by taking on the reversed role from the Project Tracker.
- Makes it clear to the client what’s blocking progress, and the client-side tasks that needs to be completed to move forward.
- Makes clear the relationship between blocked features and the specific stories that are causing the block.
Cons
When story priorities change in our Project Tracker, these priorities aren’t automatically reflected in the API Tracker. The anchor or the lead has to manually re-prioritize stories in the API Tracker whenever there are changes in the Project Tracker.
Staying Connected is the Key
I’ve found it helpful to schedule a daily chat with the lead developer on the other side, particularly around the peak of API development. The idea of this meeting is to highlight new stories that have been created, discuss any outstanding questions, and to go over rejected stories. The meeting should be short (<15 minutes), and easy to move if there’s no outstanding issues that day. To stay true to agile, it’s not the tools that you use to stay on top of dependencies that matter, but keeping a high bandwidth in communication between teams.
About the Author
