Velocity is used for measuring the rate at which scrum development teams consistently deliver business value in other words quantity of work a team can accomplish within a sprint. In simple terms, velocity is the sum of the story points that a team can deliver in an iteration. It can be measured in terms of the Story Points, days, ideal days, or hours a team can deliver per sprint of a given length, and with a predefined Definition of Done (DoD). Velocity helps a Team to forecast how many Sprints they need to develop new features. Following its ups and downs also allows a Team to analyze the progress they make as a result of any recently implemented improvements. Generally, the most recent 3 iterations are considered to calculate the average velocity of a team. But let us consider the case of the first iteration, where the project team comes together for the very first time. The choice of velocity in such a case could be done in one of the following 3 ways: Based on historical data, By running a few iterations, Deduce based on expert judgment or hypothesis.
Average sprint velocity
It is usually taken over the last three iterations and can help R&D leadership understand how much a team can get done, and plan their workload for future sprints. This is called the “Yesterday’s Weather” pattern.
First iteration’s velocity
For an agile team’s first iteration, a general guideline is to plan initial velocity at one-third of the available time. If you’re estimating ideal programmer time then this account for meetings, email, design, documentation, rework, collaboration, research, etc. If using actual time, include enough of a buffer to account for standard project overhead and estimation inaccuracy. Also, remember that velocity will quickly emerge during the first iteration. If underestimated, velocity in the first iteration will rise as new features are included; and if overestimated, velocity will decrease as features are removed. For the second iteration, the Scrum team should then use the first iteration as a guideline.
Velocity Measurement
The team planned to tackle 41 story points in their first sprint. They completed 28 story points and rolled 13 story points over to the next sprint. So their velocity is 28. Only tasks marked as ‘Done’ count, even if there’s only a tiny bit of work left to do in the task.
The steps involved in Velocity-based Sprint Planning are as follows:
Calculate the team’s average velocity (from the last 3 Sprints)
Select the items from the product backlog equal to the average velocity
Verify whether the tasks associated with the selected user stories are appropriate for the particular sprint
Estimate the tasks and check if the total work is consistent with past sprints
Benefits of Velocity-based Planning
Velocity-based planning is considered due for the following 4 main reasons.
Accounts uncertainty in planning – Since the size of a user story is a mixture of effort and uncertainty this method takes uncertainty into account while planning.
Effective release planning – The detailed sizes of the stories can lead to a more value-added release planning with the identified dependencies/assumptions and their impact on the release flow.
Accounts overhead within the user story – velocity-driven commitment encourages through the completion of the story in all aspects. When the team inspects to increase the velocity, they will point out the waste that is affecting the velocity most and the stakeholders can work on it.
Enforces a culture of honoring the commitment – After a few sprints of achieving the commitment, the team gets used to it and the culture causes the team to actively reduce waste or inspect their own development processes triggering the continuous improvement.
Burndown Chart
The Burndown Chart (sometimes called a scrum velocity chart) is a visualization of sprint velocity. It shows the time remaining to complete the planned user stories for each day of the sprint. The slope of the burndown chart makes it possible to predict the outcome of the sprint—extend the chart until the X-axis to see when the stories will be complete—ahead of time, on time, or later than planned.
There
are three basic burn-down strategies:
Burn-down points by the completed Sprint Backlog items. The items must be small enough to be completed within one-two day. Otherwise, bigger items would result in more stair-stepping and a less clear burn-down line.
Burn down points by the completed end tasks. This implies that Planning Poker is used to estimate the end tasks in points. This approach takes more time during planning but doesn’t require small backlog items to have a clear picture for Velocity.
Burn-down hours by the completed end tasks. This implies that the end tasks are estimated in ideal hours during Sprint Planning. This is similar to the previous point.
Benefits of Velocity Charts
Track overall project status – The velocity chart computes a number of project trends such as accepted stories by type, volatility metrics, and iteration velocity. This makes the velocity chart ideal for monitoring the overall project status.
Track volatility – Volatility is a measure of predictability. Frequent velocity valleys and peaks may show you an unpredictable project, while iteration-by-iteration velocity implies a predictable one.
Know velocity trends – Accepted story points may be less for a specific iteration when there is a large number of Zero-point stories, chores, or bugs. This chart makes these chores/bugs visible clearly by exhibiting iteration velocity dips along with an increase in accepted bugs.
Improving Sprint Velocity—a Few Caveats
One of the goals of R&D leadership is to increase agile or Scrum team velocity over time; to achieve more with the same resources. While this is an important goal, it can’t be followed blindly:
Velocity does not equal business value—a team might roughly deliver the same quantity of working features for years. Their velocity is the same, but due to their improved professionalism, teamwork, and experience, they can deliver more value and higher quality within the same story points.
Velocity can come at the expense of quality—teams that are pushed to deliver more, faster might have no choice but to cut corners and reduce practices like unit testing, code reviews, UI and usability testing.
Velocity is a fluid concept—in agile, velocity is determined by subjective story point estimates and depends on the Definition of Done. Teams measured only by velocity will have a strong incentive to estimate more points or lower DoD criteria.
Improving Velocity
Increase Quality – An investment in quality always pays off in improved productivity down the line. E.g. code reviews, test automation, and bug fixes. Continuously focus on refactoring code, so as to remove all traces of technical debt. Any code that is not used has to be removed. A simple and flexible design and code are always easy to estimate and be worked upon.
Stop Wasting Time on Unnecessary Tests – Here are three examples of tests that are probably a waste of time: Test overlap, Testing unused features & Testing code that hasn’t changed
Optimize Sprint/PI Planning Meetings – The agile methodology advocates not planning too far in advance, or in too much detail, so stick to just-in-time planning. So in PI planning plan a few sprints in advance with detailed task breakdowns for the immediate sprints. This added visibility helps to see dependencies, identify challenges, and consider approaches and technical solutions in advance. Ensure team members are fully focused and they can keep distractions at bay.
Sprint Retroactive and Process Review – It’s important not to turn the retrospective into a “venting session/” Problems discussed during the session must be taken seriously and leaders must spend the necessary time to resolve them.
Add External Resources or Training – For one-time or repetitive activities either add external resources or train existing resources. E.g. infrastructure support, test automation frameworks
Engage customer – Engage with the customer and solicit his presence so as to clarify requirements, bounce ideas, or seek feedback often.
Capacity in Sprint Planning
Capacity is the total number of hours the team is available, not how much quantity of work getting done. The highest priority user story is taken and broken down into tasks. Each task is estimated in the number of hours and accommodated in the capacity. If any capacity is left, the next high-priority user story is taken, and the process continues until there is no more capacity left.
There is an efficient way to account for changes in Capacity and get a refined Velocity forecast. The steps are as follows:
Calculate the maximum Capacity of your Team in man-hours, assuming that you have ten working days in a two-week Sprint and all the team members are available.
Calculate the adjusted Capacity, considering all the Capacity loss you will have in the upcoming Sprint.
Get the ratio of the adjusted Capacity to the maximum capacity.
Apply this ratio to your current average Velocity.
Here is an example:
Imagine we have 9 team members, who work within 2-week Sprints 40 hours a week. The maximum Team’s Capacity is: 9 * 2 * 40 = 720 hours.
Now imagine, that 1 software engineer and 1 business analyst are going to have their 2-week vacations during the next Sprint and all the team will be away on holiday. So, the adjusted Capacity is: 720 − (2 * 40 * 2 + 9 * 8) = 720 − 232 = 488 hours.
The ratio is: 488 / 720 = 0.68
If the average Velocity for the previous three Sprints was 160 points. Then the refined forecast for the upcoming Sprint is 160 * 0.68 = 109 points.
Benefits of Capacity based Planning
Capacity-based planning is considered due for the following 3 main reasons.
The capacity of the teams may vary from one sprint to another, depending on holidays, leaves, or other commitments. So, every sprint is not an average sprint.
The story points and the velocity are the two important measures over multiple sprints for estimating the release dates. But story points are found to be coarse-grained for planning the details of a two-week sprint. If you consider the hours, they are fine-grained enough and much useful for estimating concrete tasks.
Lastly, in the Sprint Planning, the user stories allow the development team and the Product Owner to consider each story in detail to develop a shared understanding of the end product.
Drawbacks of Capacity-based planning
Capacity-based planning has a few drawbacks
Assumes estimates are accurate – Committing the sprint size based on available capacity assumes that all task estimates are accurate.
Assumes all tasks can be done in parallel – The expectation is that all the team can work in parallel during the sprint which is practically difficult to achieve unless each task is independent.
Considers everyone as equal – The capabilities of the team members vary; hence the time to achieve the task as well based on the respective owner.
Makes User story sizing irrelevant – If the team does not use the sizes of the user story to load a sprint, then the entire exercise of sizing them becomes irrelevant to the team.
Non-functional Activities
Every
Development Team always has “non-value” items in their Sprint Backlogs such as:
Technical enablers – It does not give anything tangible to the business right now, but they unblock future development.
Exploration spikes – These spikes are not the features that can be demonstrated during the Sprint Review. However, they give a Team vital knowledge of how to do the right things in the right way.
Refactoring and other technical debt – These deals with already delivered functional parts are much less interesting than the new features. However, only high code quality makes frequent delivery possible.
If you don’t invest in these then products will get blocked or stuck at some point of time. To ensure a healthy balance between these non-value and value items, allocate effort or alternatively explicitly agree that Velocity is calculated based on functional items only & make the Velocity calculation as transparent as possible.
Bug-fixing Activities
Bug-fixing can be viewed as part of the technical debt discussed above, many treat it as an integral part of the development process. The more defects discovered in a Sprint, the less new functionality the Team is able to deliver. In order to this risk, it is better to have a clearly defined place for bug-fixing in Velocity.
Include estimations for bug-fixing into every Product Backlog item during Sprint Planning. In case of more complex items, where there are greater development risks, allocate more points for bug-fixing.
Allocate some fixed number of Velocity points for bug-fixing for all the Product Backlog items in a Sprint (like for the technical spikes or the technical debt).
Don’t allocate anything for bug-fixing, so Velocity will be just lower and its oscillations will be less clear. In other words, you do the required bug-fixing every Sprint without reflecting anywhere on the effort spent. This impacts the Team’s Velocity as the Velocity “automatically adjusts”.