Information radiators in Agile are meant to display information at a public place so that the information can be noticed by as many people as possible without making a conscious effort to do so. Very less people know that the idea of information radiator was invented by Alister Cockburn, who was a big believer in effective and timely communication. Information Radiators should display the current information about the project whatever is critical for the team to learn. It could include Schedule, tasks, issues, progress etc. Let’s now talk about the less known forms of Information Radiator Velocity Charts.
Velocity Charts
Along with burn down charts, measuring the velocity of agile teams has proven to provide tremendous insight/visibility into project progress and status. A velocity chart shows the sum of estimates of the work delivered across all sprints. Typically velocity will stabilize through the life of a project unless the project team make-up varies widely or the length of the sprint changes. As such, velocity can be used for future planning purposes. While typically reliable for a couple sprints out, if you accept that priorities, goals, and teams may change over time and therefore the confidence level of a sprint far in the future, velocity can be used to plan releases much further into the future. A typical velocity chart for an agile project team might look like the image here.
Some of the guidelines for preparing Velocity Charts are as follows. Like most agile practices, these are guidelines, not rules that are meant to prevent common sense.
- Velocity is the sum of the estimates of delivered (i.e., accepted) features per sprint.
- For an agile team’s first sprint, a general guideline is to plan initial velocity at one-third of available time. If you’re estimating ideal programmer time then this account for meetings, email, design, documentation, rework, collaboration, research, etc. As an example, with six programmers and two-week sprints, a total of 60 programmer-days (6 programmers x10 days) are available. In this situation, a good start would be to plan 20 ideal days’ worth of work in the sprint. If using actual time, include enough of a buffer to account for standard project 1) overhead and 2) estimation inaccuracy.
- Also, remember that velocity will quickly emerge during the first sprint. If underestimated, velocity in the first sprint will rise as new features are included; and if overestimated, velocity will decrease as features are removed. For the second sprint the Scrum team should then use the first sprint as a guideline.
- Velocity is very much a localized measure. In addition to different team members with different team ‘personalities’, projects typically possess unique characteristics in terms of estimating techniques, detail process, technology, customer involvement, etc. As a result, this can make organization-wide analysis very inaccurate.
- Velocity will typically fluctuate within a reasonable range, which is perfectly fine. If velocity fluctuates widely for more than one or two sprints, the Scrum team may need to re-estimate and/or renegotiate the release plan.
- For most agile development teams velocity will typically stabilize between 3 and 6 sprints.
- Future sprints use the proven history of the team to determine how much the team can do. Therefore, velocity is the right measure to use for planning future sprints.
- Maximum velocity DOES NOT mean maximum productivity. In an attempt to maximize velocity, a team may in fact achieve the opposite. If asked to maximize velocity, a team may skimp on unit or acceptance testing, reduce customer collaboration, skip fixing bugs, minimize refactoring, or many other key benefits of the various agile development practices. While potentially offering short-term improvement, there will be a negative long-term impact. The goal is not maximized velocity, but rather optimal velocity over time, which takes into account many factors including the quality of the end product.
- Velocity’s value comes from its inherent consistency. A fixed sprint length helps drive the reliable rhythm of a project. Without this rhythm, you are constant revising, re-estimating, and reconciling, and the ability to predict out in the future is minimized due to inconsistent results. If, on the other hand, almost everyone is going to be out a week for the holidays or a couple days for company-wide meetings, then by all means simply use common sense and adapt sprint dates or velocity accordingly.