Rabu Input File Example

The name of your project.

The date that you last updated the information in this file.

A list of all the iterations to date for this release. Put your current iteration first.

Each iteration gets an object of its own.

The date that the iteration started.

The length of the iteration in calendar days. (In this example, the iteration is one week long.) Note that the value is a number, not a string.

The velocity of the iteration. For your current iteration, use your estimated velocity. For completed iterations, use your actual measured velocity.

Risk multipliers describe how much schedule risk you have, which determines how much spread there is in your schedule projections. They're described in detail here. The easiest approach is to use the following rules of thumb:

Rigorous projects: If your team achieves the same velocity every iteration, gets everything "done done," and you fix all your bugs each iteration, then you probably don't have much schedule risk. Use [1, 1.4, 1.8] for your risk multipliers.

Risky projects: If you don't meet the "rigorous project" criteria, you're more likely to have a lot of schedule risk. Use [1, 2, 4] for your risk multipliers.

This is a list of all the features that will be included in your schedule projection—typically, the features you intend to ship in your next release.

Rather than listing out every story in your backlog, combine groups of stories into "features" that your stakeholders are interested in. You should only have about five features; if you have too many, you're likely to overwhelm your stakeholders with more detail than they care about, which will make discussing tradeoffs difficult.

Each feature has a name (such as "Smaller page size" in this example) and an estimate of the work remaining. This estimate is the sum of all the remaining stories for the feature. An estimate of zero means the feature is done. Note that the story estimates are numbers, not strings.

You may also list features that are not included in your schedule projection in the "excluded" section. Use this to list features that your stakeholders are interested in, but that you have decided not to ship at this time. This helps define the boundaries of your work and creates the opportunities to explore trade-off scenarios with your stakeholders. This section is optional.

That's everything you need to describe an iteration.

After the current iteration, you may list each previous iteration from most recent to least recent. These historical iterations are optional. If present, they'll show up in the Rabu burn-up chart. We recommend erasing the history at the beginning of each release cycle so that the burn-up chart shows your progress towards your current release.