Velocity is a core metric for tracking the progress of Scrum teams. If velocity is stable, everything is on track. But what happens when it isn’t? What can cause velocity to slow or become erratic, making agile estimation more difficult?
In this article we will cover five common antipatterns that can negatively affect velocity and best practices you can use to avoid them. By avoiding these antipatterns, you can help your Scrum team move a few steps closer to high, predictable development velocity.
What is Scrum?
Scrum is a framework for managing software development teams, originating from lean and agile methodologies. Scrum is based on “time boxing”—teams work in sprints of 1-3 weeks, and in each sprint the team must release a limited scope of working functionality.
A well known (but not mandatory) feature of the method is a short stand up Scrum meeting for daily synchronization.
Scrum principles
Among the important principles in the Scrum framework are:
- Value individuals and interactions over processes and tools
- Value working software over planning and documentation
- Value collaboration over contracts or negotiation
- Value change and flexibility over adherence to plans and specifications
Scaling Scrum
Scrum is suitable for small teams of 3-9 developers. It can be scaled to large organizations with hundreds or thousands of developers using systems like the Scaled Agile Framework (SAFe) or Large-Scale Scrum (LESS).
Scrum hierarchy of work units
- A release is a new version of the product delivered to customers.
- An epic is a group of features around a certain theme which is part of a release, but is too big to be delivered in a single iteration.
- A sprint is a group of features planned to be completed by a single team in one iteration.
- A user story is a feature or piece of functionality defined from the end-user’s perspective. For example, “as an administrator, I want to change user permissions.” Stories are estimated using story points, an arbitrary number chosen by the team that signifies how large or complex a user story is to complete.
- A task is part of a user story which is done by a specific member of the Scrum team, and takes no more than one day.
Scrum metrics
Metrics commonly used to track the progress of Scrum teams include:
- Number and trend of production defects
- Planned-to-done ratio
- Customer happiness
- Level of technical debt
- Team communication and enthusiasm
- Velocity—the focus of this article
What is Scrum Velocity?
Velocity is the amount of work a Scrum team can achieve in a certain period of time. Scrum velocity can be calculated at several levels:
- Velocity of individual tasks (also called cycle time)—How long does it take the Scrum team to turn over individual tasks? A Control Chart, shown below, is a visualization which shows velocity by task. Circles that “float up” on the chart are tasks that took a long time to complete and should be investigated. Progress within a sprint can also be visualized by a sprint burndown chart.
- Velocity at the sprint level—How many story points is the team managing to complete per sprint? A higher number indicates more functionality delivered to users. However this metric assumes the team is adhering to their “Definition of Done”; criteria for releasing a user story, which might include code review, testing, documentation, etc.
- Velocity at the epic or release level—An epic or release burndown chart in Scrum tracks how much of the originally planned scope of the epic or release has been completed. It’s very important to track scope creep: additional requirements or user stories added during the Scrum lifecycle, after the start of the release. Below is an example of a burndown chart for an epic which indicates work added during the cycle.
Scrum capacity vs. velocity
It’s important to clarify the difference between scrum capacity and velocity. Capacity measures how much time the team has available, not how much they are getting done. A Scrum team member is considered to have 6 productive hours a day, or 30 hours over a typical work week.
Scrum velocity formula
Actual velocity, a measurement of how fast teams are moving, is measured as follows:
Actual Velocity = Total Number of Story Points Completed / Number of Sprints
Expected velocity, a measurement of how fast teams plan to be moving, is measured as follows:
Expected Velocity = Total Number of Story Points Committed / Number of Sprints
What Can Go Wrong with Scrum Velocity?
Antipattern #1: Setting Targets for Velocity
Agile velocity is meant to be an empirical measure of a team’s progress, which can be used for estimation—not a goal or metric by which team performance is measured.
Setting velocity targets can be misleading, because Scrum story point estimates are subjective. Giving a team a goal of 30 story points per sprint might be meaningless, because the team can subjectively define what scope of work 30 story points actually means.
At the same time, velocity is something that is within a Scrum team’s control, and it is a variable of prime concern to management. Velocity must be upheld and improved over time as teams improve the Scrum process, adopt new tooling, and become more proficient.
Bottom line: R&D managers can aim to improve velocity. However, this should be done by helping teams improve processes and remove obstacles, not by setting a quantitative velocity goal.
Antipattern #2: Expecting Instantaneous Maximum Velocity
New Scrum teams, existing teams starting a new project or switching to a different type of work, all must go through several iterations before they get into a rhythm. The team needs to learn how to cooperate and distribute work between team members, understand the complexity of tasks within the sprint plan, and adapt to outside dependencies and requirements.
Additionally, at the outset, Scrum teams and managers will not be able to accurately estimate velocity. The premise of Scrum is that only after you “get your hands dirty,” build software and bring it to production readiness, do you really understand the full process and the complexity inherent in the work.
Bottom line: Wait for Scrum teams to mature and realize their full potential before estimating velocity.
Antipattern #3: Work Not Broken Down into Granular Pieces
An essential component of Scrum is working on small pieces of work that are easy to understand, scope and estimate. Software projects are broken down into epics, sprints, user stories and tasks, and team members churn through one task at a time.
The problem starts when teams don’t break down items with sufficient granularity. For example, a user story is defined as a large effort that might take a week to develop by several team members. A symptom of this problem is that the burndown chart drops sharply in the middle of a sprint. This can be a root cause of erratic or decreasing velocity from sprint to sprint.
Bottom line: Break down work into small pieces to make planning simpler and velocity more predictable.
Antipattern #4: No Slack
To be effective, a Scrum team needs some “slack” or idle time built into its sprints. A common rule of thumb is to plan for 20% slack for ongoing communication, teammates to pair and solve problems, and addressing urgent issues or interruptions.
Planning sprints with no slack in order to increase velocity will probably only decrease it. Team members will focus on completing their tasks and adopt an “I am busy” attitude; something which over time erodes the team’s cooperation and problem solving abilities. To be agile, a Scrum team needs some shoulder room.
Bottom line: Teams with no slack time become “busy” and overly focused on individual objectives, hurting their velocity in the long term.
Antipattern #5: Testing, Technical Debt and Known Bugs
One of the biggest fallacies in estimating velocity is that the output of a sprint only consists of new features delivered to the customer. Virtually every sprint will also contain:
- Time to build and maintain automated tests
- Time to respond to test results and fixed bugs
- Previous known bugs
- Technical debt from previous sprints
While these things do not add new functionality a user can play with, they do add tangible value for end users in the form of higher quality. Management must allocate some of the resources of their Scrum teams (often a large portion) to these additional elements. Otherwise, software quality will deteriorate and make things much more difficult in future sprints.
Bottom line: Without an investment in quality, users suffer and projects move slower in the long run.
Scrum Velocity Best Practices
The following best practices will help you avoid some of the antipatterns we listed above and help Scrum teams move faster:
Use empirical data to set expectations
Observe actual team velocity for similar tasks, and plan future velocity based on that. Don’t set unreasonable “goals” pushing teams to go faster, without addressing underlying parameters that affect their productivity.
Plan sprints in detail (but not too much)
Agile/Scrum is famous for getting rid of meticulous planning. We don’t want 400-page requirement documents. But breaking down features into stories and tasks correctly, going into detail and uncovering complexities or unknowns at the sprint planning stage, will improve your ability to estimate and predict velocity.
Leave room for growth
Just like individuals in their personal lives, a Scrum team is not happy when overloaded and hyper-pressured. Some slack time to allow for unexpected events, cooperation and problem solving, will go a long way towards establishing a productive Scrum culture.
Add Quality Intelligence to your toolset
A large percentage of any Scrum team’s workload is made up of testing, bug fixing and technical debt. A new category of tools called Quality Intelligence Platforms can help you get accurate data on which tests are worth investing in. And conversely, which new tests are a waste of time because they relate to features at very low risk of quality issues.
By smartly prioritizing testing work, you can save time for new user stories and help teams move faster. SeaLights is a platform used by many Scrum teams to become more efficent.
If you’d like more practical advice on reducing the time invested in testing and leaving more time for new features, learn more about Quality Intelligence.