Agile development just isn’t successful without a solid plan. When time, budget, and quality are fixed variables, how can you predict the scope of work your team can accomplish in one sprint?
The answer is historical data.
Today, we're expanding our reporting suite with Velocity Charts: a handy tool which displays your team's historical speed of work. They provide a simple, at-a-glance picture of your velocity, as measured by the total number of story points closed in recent Milestones. This way, you're able to see exactly how much value your team can ship each sprint.
And since they're built using live GitHub data, you'll know they're always accurate.
Why velocity tracking matters
The point of tracking velocity isn’t to generate a nice-looking report for your boss.
Universally, we tend to overestimate the amount of work we can complete in a given time period. Measuring actual velocity – how much work we really get done – enables us to plan more accurately, making us much more likely to achieve our goals!
In isolation, the amount of work completed in one Milestone isn’t very helpful. Factors outside your control – a sick teammate, an unexpected bug – are bound to pop up. Life happens. Viewing work completed over time, however, becomes a valuable piece of insight.
Why do we measure team velocity and not individual productivity? In his book The Agile Samurai, Jonathan Rasmusson puts it this way:
When we create plans based on our team’s velocity, we are making a commitment as a team. We’re saying, “We as a team feel we do deliver this much value, each and every iteration.”
[...] If you want more bugs, more rework, more miscommunication, less collaboration, less skill, and less knowledge sharing, then by all means, promote, highlight, and reward individual developer productivity.
Just understand that by doing so, you are killing the very spirit and behavior we want to foster and promote on our projects: sharing ideas, helping each other out, and watching for things that fall through the cracks.
Well said, Jon!
To see your team’s velocity inside GitHub, follow these steps:
If you haven’t already, start adding Estimates to your GitHub issues and pull requests. (If you're not sure how to estimate tasks, read our guide on the topic!) This will allow you to track their progress in reports later.
When you're preparing for a sprint, you'll add your estimated issues and pull requests to a Milestone. You can give the Milestone a descriptive name, and don't forget to set both a start and an end date! Most teams choose two or four weeks.
After you've completed a few sprints, you'll have some historical data in your velocity charts. To view them, click the new Reports tab, and select Velocity tracking.
ZenHub will automatically display up to seven recent Milestones, in addition to current Milestones. Hover over each bar to see more detail. The blue line denotes the average number of story points (estimates) closed each Milestone – open story points do not count toward this total.
Note: You can get a broader view of velocity by connecting repositories together. Learn how.