Thuật ngữ Velocity trong Agile là gì? Luyện thi PMI-ACP

Now that we have understood what a Story point is and why we should be using story points for our estimation, it is time we learnt another key Scrum topic – “Velocity”.

Velocity is a term that is very frequently used in Scrum Projects and to be fair, is very easy to understand. When you start working on an Agile project as the Scrum Master, you will be responsible to measure the velocity of your scrum team and hence it is very important that you understand this concept well. The purpose of this article is to do just that.

What is Velocity?

In physics Velocity refers to the speed at which an object is moving in a particular direction. Without Direction, we only have Speed which may not be as useful as when we know the Direction. The meaning of Velocity in Scrum is very close to what we know in Physics.

To put it simply – Velocity is simply a measure of how fast the scrum team is going towards achieving the product functionality or goal. We measure this at the end of every iteration and use the number to predict how much the team may be able to deliver in upcoming Iterations as well.

In real life projects, Velocity is nothing but the total of the Story Point Estimates of all the feature user stories the team was able to complete in the Sprint or Iteration under consideration.

Again, the emphasis here is on achieving product functionality because the team may be able to build a lot of things but if they do not contribute towards the product functionality that can be shipped out to customer, they do not count towards Velocity.

A simple example here would be bug-fixes on code. While the team is testing a user story, they may identify bugs in the code and would eventually fix them during the Sprint. As bug-fixing is part of the initial story point estimate that was given for the story, a fresh estimate is not required and hence this effort does not contribute to Velocity.

Are Work In Progress Stories Counted towards Velocity?

One of the biggest questions new Scrum masters have is; whether Work In Progress User Stories contribute toward Velocity. The Answer is “No”. let me explain…

Firstly, Scrum recommends that user stories be broken down into smaller/granular pieces that can be completed in a single Sprint or Iteration. If for some reason the team is unable to finish a certain user story, the partial completion of the user story does not contribute towards the Velocity because the story was not “Completed” and hence does not add any value to the Product as a whole.

You may be wondering what about the effort spent on that partially completed user story and why it did not contribute to the teams Velocity – are you?

Like I explained in the previous paragraph, Velocity is a measure of the usable or shippable functionality the team was able to produce in a sprint. Half-finished work items will not be counted towards the Sprint’s Velocity for the team.

On a related note, Scrum recommends that, at the end of each sprint, the team review such unfinished story with the product owner to decide whether it is worthwhile to continue work on the story or should they focus on any newer or higher priority user story.

Keeping Teams Velocity Clean

Sometimes, Scrum teams pay a lot of attention to the velocity and try to do stories just to boost up the velocity. There could be activities the team does as part of their job (maybe code refactoring or environment maintenance etc) that don’t really count towards the teams velocity. A team that understands its purpose does not bother about these day to day activities while some scrum teams try to create user stories even for such routine activities just to boost up their velocity output for the iteration.

A team’s velocity is the number of story points that it can complete in a single iteration.

Any time we hear a team talk about including some work they’ve done toward the velocity being counted, it’s a bad sign that something is amiss. Often this is the result of a culture that is overly focused on looking at velocity as proof the team is delivering stuff towards a release. Sometimes, this pressure for a high velocity comes from the team itself.

Setting a target velocity to aim for the team is a good idea but, achieving a velocity should not become the team’s goal. The team’s goal is to deliver incremental improvements to the product – PERIOD.

USE VELOCITY WHEN PLANNING ITERATIONS

Before you plan an iteration it’s critical that your team understands its velocity. A team’s velocity is the number of story points that it can complete in a single iteration. Put even more simply, your team’s velocity is how many story points it completed in the last iteration. It’s not how many points the team planned to complete. It’s how many were actually completed based on the acceptance criteria defined by the product owner. This is commonly known as yesterday’s weather. It will take a few iterations before the team will truly understand its velocity, but over time, the team will settle into a common understanding of how many story points it can commit to in a single iteration.

In the screenshot shown above the team completed

13 story points in iteration 1,

14 story points in iteration 2, and

10 story points in iteration 3.

In this example, the team’s velocity is 10 story points… it’s not 12.3 (the average), and it’s not 14 (the max). It’s 10 – the number of story points completed in iteration 3. As the team enters the planning meeting for iteration 4 it should know and understand its velocity so it can have a healthy conversation with the product owner about how many points it can commit to in the next iteration. There are good likely reasons why the team completed fewer points in iteration 3 than iteration 2. Was someone on the team on vacation? Did the team over commit and not complete a story? Those reasons should be known by the team and should have been surfaced during the team’s retrospective.

As the planning meeting begins, the product owner and the team start to discuss and select stories to include in the next iteration. If the top four stories on the product backlog have story points values of 3, the team will know that if they commit to ALL those stories they’ll be committing to more work (12 points) than they completed in the last iteration. If the take only 3 of those stories, they’ll be committing to less work (9 point). In either case, this might okay, but by using the team’s velocity the team and the product owner can have a healthy conversation about what the right stories are for the next iteration.

Using velocity when planning iterations will help your product owner to do better release planning, it will help the team make stronger a commitment, and it will lead to healthier communication with everyone involved.

Read more: Agile Estimating and Planning – Mike Cohn’s book

Velocity of team: the (average) number of story points the team can accomplish in each iteration used to estimate the project timeline and set expectations.

Ideally, after several iterations, the velocity will become constant / gradually increasing owning to synergy and reduced risks.

For iteration 1, the velocity needs to be guessed based on historic data

Velocity usually increases over the first few iterations and reaches a plateau afterwards owing to the increase in complexity of the overall product

Velocity = the slope of a burn down graph

Factors affecting velocity:

Staffing (no of resources), morale and their skill sets

Project arrangement: interruptions / multi-tasking

If the team meets for the first time, there is NO historical data on the velocity; the initial velocity (known as “forecasted velocity” can only be guessed based on any available data.