Dell’s corporate choice of Agile Planning tool is Rally (if you’re wondering, my recommendation on Agile planning tools is ThoughtWorks’ Mingle). This post is rather detailed about how we use Rally, but hopefully useful more broadly. I should mention that I’ve been using Rally since 2005, so I know the tool pretty well. Our objective is to not spend time maintaining Rally (or, as we call it “feeding the Rally Monkey”) while still getting usable burn downs for our releases.

We do NOT use Rally to plan very more than 2 iterations in advance. Even if the tool made planning further easy, I would still recommend against it. I feel strongly that it’s better to have generally defined stories (aka Features or Epics) with general estimates that we call “BANKS.” Our work process is to create a wiki page for each feature that contains information about the goals for the feature and holds documentation for it as the work progresses. The wiki becomes the persistent place for the story, not our planning tool. We even embed [[wiki names]] into the story names to simplify linking.

Our planning process works like this: we create a placeholder story for each feature that we want and attach it to the release that we are working on. These features get a “BANK” suffix because they are the place holder and we put the story point estimate into these stories. You can ALWAYS see the remaining effort estimates by looking at the BANK stories remaining for the sprint. These banks are never assigned to a sprint – they are our backlog. We also maintain the priority order for these banks so we know which ones to work on first.

Before planning, marketing and engineering review the list together and make sure that our priorities are correct. If a story is finished, then we’ll accept the story. If an estimate changes, we may increase it. We NEVER lower the estimates unless the work scope changes! Reducing estimates create graphing artifacts in Rally. If we finish early, then the story is accepted and we burn off the remaining points (which shows as a progress jump towards completing the release).

On planning day, we go to the backlog and pick out the highest priority bank story. We then create another story with the same [[wiki name]] feature in the title and without the BANK suffix. We estimate the story points for this effort and remove that amount from the BANK story. Doing this credit/debit entry ensures that the release estimate remains the same. REPEATING: by removing points from the BANK story when we create a story for work in the sprint we keep the release estimate the same. This is VERY IMPORTANT if you want to show a burn up without creating a lot of stories in advance. Creating detailed stories in advance is a huge waste of time (queue the sound of a giant time sucking vortex vacuum machine). If you are doing this, stop. Really, you can stop because it is a huge waste of time on the scale of passing budget legislation in Congress.

In Rally, we do ALL of our sprint planning from the Track…Releases page (filter set to “defined” stories). This allows us to quickly see and edit the BANK stories that are in our backlog. When we want to talk about requirements or acceptance criteria, we pop over to the feature wiki page. This makes sure that we collect information across sprints. It also allows us to cross reference easily. The new stories are assigned to the sprint and we assign tasks/people to the story. We’ll continue this until we’ve assigned 100% of our team’s velocity for the sprint. At that point, we review the story point estimates and make sure that our time estimate aligns with the points (for us, 1 point ≈ 4 days). If they don’t match then we’ll adjust BOTH the story and the bank so the total is maintained.

If this sounds complicated then you’re reading it correctly. I’ve found this approach is much clearer, faster and simpler than the “right” way to do backlog planning with Rally. At the end of the sprint we accept stories and it shows a release burn up. If a BANK goes to zero then the release scope will show an increase every time we create a new story towards that feature. We do not delete BANK, we only accept them. If you’re BANK is 0 and the feature is not complete then your estimate was wrong. That is good information to track and the increasing in release scope is an accurate reflection of your backlog.

Wow – this post ended up with a lot of very technical Rallyisms. I’d be interested in hearing how you’re using the tool or what you think of these recommendations.