This is a repost of a series of article originally published on Songbird’s blog
Previously, we’ve examined the new development practices that the Songbird team adopted to plan and track a release. Everyone on the team was very eager to put them to t…

Rally has won the last three consecutive JOLT Awards as Best in Class project management software.

We would like to learn about your interest in agile and welcome an opportunity to set up a phone conversation with you. Please let us know if there is anything that we can do to support you.

I can be reached by email or phone 720-921-8147.
Best regards,

Mike Hayes
Rally Software Development
http://www.rallydev.com

Yeah, always fun to look for great bands/artists. Our planning period is typically 2 weeks. We try to get a head start during the QA phase of the previous release in an attempt to overlap release trains as much as possible. In practice, it turned out to be very challenging as often time the whole team is still focusing very hard on releasing the current bits.

What we’ve learned is that planning is very much a full time activity. You need to allow for the product manager, designer and engineer to iterate over stories, design docs and prototypes to increase the accuracy of our costing estimates.

As far as anticipating scope changes based on requests, we allocate a certain point budget over the course of the release for what we call “intake”. This allow us to accommodate small variation in plan and regressions. For more drastic changes, you have to revise your plan and trade features to make room.

Question – how far in advance of starting development do you plan out your sprints?

For e.g. we have a rough idea of the features we want to add and when we would like them in over the next 6 months, and we are trying to get to the point where designs and prototypes are at least one sprint ahead so we can task and estimate ahead of time.

I think the hardest part is striking a balance between planning far enough in advance to have a good idea about the release timeline, but not too far in advance that you are weighed down with the future and not the present.

Also, we need to account for the “agile” piece where scope changes or artist requests come in. Do you have buffer at all for that?

I’m looking forward to the tools…we just Jira and Confluence and I’m evaluating Project Mgmt tools right now: http://tarabrown.pbwiki.com/Agile-Project-Management-Tools

You should expect Songbird to use at least as much memory as Firefox. Especially if you have a few tabs open and web pages in them. It is a browser after all.

There are however, lots of things we can do to get memory usage down still. We won’t be focusing solely on that though since we still have a lot of features that need to come in over the next months.

Good observation. I should have clarified that the charts don’t capture data at the same time. The burn down chart represents the total points at the beginning of each iteration. The velocity is computed at the end of the iteration, and plotted as the velocity for that week.

In the case of Eno, we started the first iteration and still had some items in the plan that we were not sure should make it in the release. During that first iteration, we pruned the list so it would be ready for iteration 2. That’s the negative intake velocity.