In agile development, we use the principle of “yesterday’s weather” for predicting how future iterations should be planned. In other words, today’s weather is likely to be the same as yesterday’s. When story points are mapped to difficulty or complexity, rather than to hours or days, a team is most likely to do about the same number of story points in the current iteration as they did in the past few iterations.
Tracker was designed to automatically plan your iterations for you based on the average amount of story points you complete over a predetermined number of iterations. We call this average velocity, and in Tracker, velocity is the governing force behind every project. It determines what will be planned for future iterations and is constantly changing based on your actual rate of completion.
For more on the basics of velocity, please see Planning with velocity. Read on for tips to ensure your project’s velocity is an accurate reflection of your team’s work each iteration.
Velocity guidelines
A predictable cadence helps your business plan, and tracking velocity helps rate that predictability. Each team and project has a velocity that’s unique to them, just as the points each team uses for estimates are meaningful only in that team’s context. You can’t compare velocity across teams or projects. However, Tracker users can benefit from some general guidelines to make sure their velocity is a dependable reflection of their work.
It’s about the conversation
Yes, velocity does give you a glimpse into the future, in the form of more realistic estimates of when milestones will be hit, at least compared to wishful due dates. It’s obviously just an approximation, though, and the velocity number itself is not meaningful outside the context of a given project.
What’s really valuable are the conversations that story estimation encourages within development teams (and their product owners). Conversations that uncover all kinds of assumptions and hidden scope, and give the product owner the insight to make value decisions at every step (e.g., is that 5-point feature really worth it, or is there a simpler alternative?), which all leads to a leaner, better product, and a more direct path to the finish line.
Having a crisp, prioritized backlog of estimated stories and a steady velocity lets you have constructive conversations with your stakeholders when you face that inevitable change to requirements. Dragging those new stories into the Backlog gives you immediate feedback about how the scope increase will affect the future timeline and planned releases, and allows you to make tradeoff decisions (e.g., “OK, let’s move these other stories down so we can still make that milestone”).
These conversations are where all the important tactical decisions are made, and there will be many, as you keep learning as a team, and the world keeps changing on you. Each one takes you closer and closer to winning the battle (and shipping great software).
Consistency is Key
Steady state allows you to predict, at least roughly, when your project will hit important milestones. This gives your business the ability to plan ahead and to make meaningful tradeoff decisions (usually scope vs. time) as you discover more scope (and you always do). Predictability is rare in the software industry, and only comes when you get your project to that zen-like state of steady, consistent pace, measured by low volatility (of velocity).
Achieving low volatility takes an ongoing effort, but the practices that collectively yield it are worth the effort on their own merit. Break down large features into small stories (that fit into a single iteration), estimate as a team, maintain a constant ratio of features to bugs and chores every iteration, deliver stories continuously, and have your product owner highly involved, available, and accepting those stories daily.
Adjusting for realistic velocity
There are three key project settings that directly relate to and affect your velocity: Initial Velocity, Velocity Strategy, and Iterations Length. You can set these to realistically reflect the true capability of your project team at a given point in time.
Initial Velocity
When starting a new project, there are no past iterations with which to calculate velocity. In these cases, Tracker uses an “initial velocity” metric; however, after one iteration has been completed, Tracker begins calculating the velocity on its own. Initial velocity defaults to 10; however, you can change this to whatever value you feel to be most appropriate.
Velocity Strategy
This is the number of iterations Tracker uses to calculate your velocity. The default is three; however, you have the option to choose anywhere from one to four iterations.
Iteration Length
This is the length of your iterations in weeks. All new projects default to one-week iterations; however, you can choose anywhere between one and four weeks.
The velocity calculation formula
How velocity is calculated is fairly straightforward: it’s the sum of all “normalized” points completed over a given set of iterations (based on project settings), divided by the combined length of all those iterations, in weeks. Normalized points are the number of points the team would have completed in an iteration at 100% team strength.
velocity_per_week(iteration_1, ..., iteration_N) =
SUM(iteration_i.points / iteration.team_strength) /
SUM(iteration.length_in_weeks)
Iterations with a team strength of 0 are excluded from both sums. The formula above always returns velocity per week. The project velocity Tracker displays is always multiplied by the default iteration length, and rounded down to the nearest integer. For example, if your iterations are two weeks long by default, Tracker will multiply the per-week velocity by 2.
Reflecting accurate capability with Team Strength
Iteration Team Strength allows you to tell Tracker about variations in your team from iteration to iteration. This helps you account for things like holidays, sickness, or other temporary team fluctuations.
For example, if half of your team leaves for a conference during one iteration, you might set the team strength of that iteration to 50%. Likewise, if your team works all weekend to prepare for launching your product, you would set the team strength to 140% (since they worked seven days instead of a normal five-day work week).
To change team strength for an iteration, click on the Team Strength icon in the iteration header.
You’ll see a dialog box come up with a field for entering a percentage. After you apply that percentage, it will appear in the header alongside the Team Strength icon.
When an iteration has a custom team strength, the points in that iteration are converted into the number of points the team would have completed at 100% team strength. As a result, team strengths between 1-99% (inclusive) increases the number of points averaged for that iteration. Team strengths greater than 100% reduce the number of points in that iteration that contribute to velocity.
Iteration Length Override
Although Tracker was designed to have consistently sized iterations, there may be times when an iteration must be set to a different length.
To edit the length of an iteration, click the date range within the iteration header.
A box will appear to allow you to edit the iteration length in weeks.
The date range for any iteration that’s had it’s length overridden will appear in yellow.
Velocity Override
Want a visual representation of what your project’s Backlog would look like if different conditions affected velocity? Velocity Override shows what your iterations would look like if your current velocity were different from its current actual value.
To use Velocity Override, simply enter your velocity value in the upper left, below your project name. A box will appear that will allow you to enter the hypothetical velocity of your choice. After entering the new value, you will see your Backlog adjust as a result. Only you will see this; other project members’ sessions will not be affected. The next time you reload your project, you’ll see the velocity revert to its actual calculated value.
Volatility
Tracker calculates your project volatility so you can visualize the consistency of your team’s work output. It’s a percentage, computed using the number of recent iterations set by a project owner in each project’s settings for velocity strategy, and reflects the variation in project velocity from iteration to iteration.
Velocity usually averages out over time, but it can vary significantly from one iteration to the next for a variety of reasons (e.g., your product has a major design change, you start using a new technology that slows the team down while they learn, business priorities shift so that more people are added to the project, or you decide to have team members spend time managing technical debt).
A simple measure of this is standard deviation, which Tracker constantly computes for your project. The velocity metric helps teams visualize whether they need to take some action to stay on track and meet desired goals.
The volatility metric for all projects in which you’re an owner, member or viewer can be seen on your Dashboard and on the Velocity chart (where you can home in on what may be behind a high volatility, and work with the team to smooth the path to a consistent pace).
