Dashboard for Agile project tracking

This is a following post to the series on Agile development at Songbird. As covered previously, we’ve created in-house tools to help with the planning and tracking of our release trains. The tool works off of Bugzilla and extracts meaningful information for project tracking. As it was originally meant to periodically generate an email status, it became apparent that it was too static for daily project tracking needs.

Songbird Release Trains

We concluded that a dashboard that was more dynamic and worked in real time with Bugzilla would provide a more accurate picture of development progress. This is an overview of the couple of extensions we added to the tool.

Dashboard

The dashboard focuses on the current iteration (all P1 stories/tasks/bugs for a release target milestone). It provides a transparent and dynamic view of what’s under active development for the week.

Items are grouped by developer so we can easily review what each person is working on in this iteration. There are few additions that make it more useful than a plain Bugzilla query. When an item is carried over from a previous iteration, it gets highlighted, providing visibility on something that may require more work than anticipated or might be blocked by some dependencies. That kind of view was lacking before and it made it difficult to figure out what was happening when tasks got carried over. Similarly, when a new task gets added to the plan mid-iteration, it’s identified as such, making the tracking of intake very easy.

Because of our code review system, often time tasks are completed from a programmer standpoint but can’t be checked in until a positive review (R+) is performed by someone else. Additionally, some code requires the re-compilation of large amounts of 3rd party libraries before the patch is available. This kind of information is now bubbled up on the tracking page so the exact status of a particular issue is visible at a quick glance.

Iteration Dashboard

This dashboard is helping us to know what everyone is doing at any given time. It fosters a sense of accountability and ownership of the issues and provides a sense of accomplishment when the work is completed.

Below is a view of the legend for the Dashboard. Most attributes for an item are extracted from Bugzilla and represented via an icon.

Dashboard Legend

Punchlist

Once a release reaches QA, a release branch is cut and the focus of the team switches from working on planned features to fixing bugs. We found that this period is best managed by using a punch list which contains all the issues remaining to be resolved before the release can ship as opposed to a weekly plan of what gets accomplished for the period. It keeps the team focused on the entirety of what’s on our collective plate. During that period, issues are being promoted to Blocker status to represent what is blocking the next milestone (e.g. Beta, RC, Final). It also signals what can be landed on the branch automatically and what needs further clearance. This allows us to throttle the rate of change being introduced into the source tree so that QA can be ensured stable builds.

Release Punchlist

When in punchlist mode, it’s critical that all issues are being assigned. The list reflects that by highlighting items that have no owner yet.

Pretty Graphs

Two frequently tracked Agile metrics are Burndown and Velocity. Those are now being graphed automatically for each release. The Burndown helps forecast when the work will be completed. The Velocity gives us a historical perspective on what the team was able to accomplish and thus helps us plan better.

The Burndown graph breaks down tasks (what we refer to as “planned work”) from bugs (unplanned consequences of software development). When the Burndown line cross the horizontal axis, we’re done. Notice in the graph below the bug points going up during the QA period.

Burndown Graph

The Velocity graph plots the team velocity, normalized per day. Actual Velocity is computed at the end of each iteration and plotted along side the Planned Velocity for easy comparison.

Velocity Graph

These new tools provide a dynamic view of the state of the release. They bring transparency into the development process for everyone involved.

  1. Sounds very cool! This is all in sdpbot, right?

  2. moragos says:

    Fascinating reading.
    I just had to read the entire “Songbird path to Agility” posts after wards!

    Good job!

  3. Stormdancer says:

    You know… people will still whine about lack of transparency. :)

    Sounds like some good planning, it’s good to see you’re thinking about this in the long view.

    Personally I hate bugzilla, but it works for a lot of folks.

    As I’m sitting here enduring ANOTHER “iTunes + Quicktime” patch forced off onto me, because I can’t get QT without iTunes… I treasure Songbird even more.

    Now, to go rip out all the idiot iTunes ’services’ … again.

  4. Jigar shah says:

    Really cool tools..I looked at how you integrated bugzilla with other systems. Personally i liked your timeline http://timeline.songbirdnest.com/client/. I daily check that to see whats up…I was thinking about our organisation to combine certain Open source free tools to integrate project management (trac), Task tracking (Bugzilla), and code review (ReviewBoard). Any plans to make your custom dashboard source open-source ? How do you track individual developer/QA’s progress…I mean for smaller team…do you have any timeline (apart from above one) to check what they have done ? Like updated docs/svn commit/bugzilla update/code review update etc ?

  5. Régis says:

    Hi Georges,

    Any plan to provide this dashboard tool?

  6. Chris says:

    What’s the deal with the new Roadmap? You’re telling us that Madonna isn’t going to be a public release anymore after saying LZ was going to be combined with Madonna for a v1.6 public release? That’s ridiculous. Hopefully all your pretty graphs and tools can show you that you need to slow down and fix more bugs rather than plow ahead with new features.

  7. Andrew Luecke says:

    @chris.. Apparently it wasn’t intended to before apparently..

    Just it wasn’t clear on the roadmap which releases were public, and which weren’t.. So I was the one who asked them to start marking the releases on the roadmap which were public or private.

    Hopefully they continue marking them in the future, so that its more obvious (because people were confused about 1.3 too).

  1. There are no trackbacks for this post yet.