If you are working in a Scrum Project, you must be familiar with the word “Velocity”. But are you aware of the term “Focus Factor” and how you can use it? In this article we are going to make it clear about “Velocity” and “Focus Factor” and how they bot are related.
What is Velocity?
It is a measure of the amount of work a Scrum Team can complete in a Sprint. It is a good metric to self-evaluate a Scrum Team on how to improve their practices, processes, tools, collaboration, etc to improve its velocity naturally over a period of time. The Velocity is calculated at the end of the Sprint because by that time the Scrum Team is clearly aware of the amount of work done in the Sprint.
Velocity is the “Sum of the Story points completed in a Sprint”. Here completed means the items that are meeting the Definition of Done. While the velocity is calculated at the end of the Sprint, the Sprint Progress should be tracked throughout the Sprint by the Developers. This will enhance the transparency to the Scrum Team on how the work is getting executed. Below is a simple way to understand the velocity with couple of scenarios:
Let us consider a Sprint of 2 weeks and below table gives the user stories pulled into the Sprint Backlog. The story points and status are also mentioned in the table for the selected user stories.
User Story Title | Story Points (Size) | Status |
Registration | 5 | DONE |
Login | 3 | DONE |
Search | 8 | DONE |
| Payment | 5 | DONE |
The velocity of the Sprint is 21 Story points, because all the user stories are “DONE” so the sum of the user stories is 21 (5+3+8+5).
Below is another scenario.
User Story Title | Story Points (Size) | Status |
Add to cart | 2 | DONE |
Change quantity | 1 | DONE |
Empty cart | 3 | NOT DONE |
Modify address of delivery | 3 | DONE |
List items of the cart | 5 | DONE |
Delete items from the cart | 3 | NOT DONE |
| Clone the cart | 8 | DONE |
The velocity of this Sprint is 19 because to calculate the velocity we have to consider only the items that are completed and meeting the Definition of Done. So in the above scenario out of 7 items, only 5 are completed and 2 are not done. So taking the items that are “DONE” the velocity is 19 (2+1+3+5+8).
Below is another scenario.
User Story Title | Story Points (Size) | Status |
Add patient data | 5 | DONE |
Edit patient data | 3 | DONE |
List patient data | 2 | DONE |
View patient details | 2 | NOT DONE |
Delete patient data | 2 | 70% DONE |
Search for patient data | 8 | DONE |
Export patient data into PDF | 5 | 80% DONE |
The velocity of this Sprint is 18 because to calculate the velocity we have to consider only the items that are completed and meeting the Definition of Done. There are 3 items which are either not done or partially done, so they will be eligible for velocity calculation. So in the above scenario out of 7 items, only 4 are completed and meeting the definition of Done. So taking the items that are “DONE” the velocity is 18 (5+3+2+8).
What happens to the items that are NOT DONE or PARTIALLY DONE?
They will be moved back to the Product Backlog according to the priority decided by the Product Owner. If they are still important, valuable and urgent compared to other items in the Product Backlog, then the Product Owner can place them on the top of the Product Backlog so that they may be taken up in the Next Sprint. The Product Owner may place them in the middle or bottom of the Product Backlog as per the latest priority. This is what is the 4th Agile manifesto value “Responding to Change over Following a plan.
Be aware of the following points when using Velocity:
- Do not use Velocity to compare different Scrum Teams, it is not meant for that
- Do not push the teams to increase velocity every Sprint, it should naturally improve
- Similar skilled, sized Scrum Teams will not have same velocity.
- Velocity is mainly to help for forecast as below:
– For Developers to see how much they can pull into current Sprint using last Sprint velocity and current Sprint capacity
– For Product Owner, to provide forecast to the Stakeholders based on most recent few (4 to 5) Sprints Best, Worst and Average Velocity
How to improve Velocity of a Scrum Team naturally?
- Creating a cross-functional training culture in the Scrum Team
- Let the team focus on the current Sprint items and avoid context switching
- Make the items small enough so that they can be done faster
- Create clear and proper acceptance criteria so that developers can understand well
- Make Product Backlog Refinement effective
- Identify the wastes that will impact the velocity such as delays, waiting, unclear requirements, dependencies etc and find the root causes of those wastes and address them continuously
What is the Focus Factor?
Focus Factor is a simple mathematical formula that helps Developers to forecast how many product backlog items can be pulled into the Sprint backlog. This number can be derived using the “Velocity” and the “Capacity” of the Developers in the Scrum Team. You are clear about the velocity in the above section of this article. Capacity is the “focused amount of time” available for the Developers after removing all the non-work related time such as meetings, Scrum events, public holidays, personal time off etc.
Formula for the Focus Factor: Velocity/Capacity
We generally consider the “Average Velocity” of the most recent 4 to 5 Sprints in the above formula. Here is an example.
A team’s average velocity is: 30 Story Points (Based on most recent 4 to 5 Sprints data)
Their capacity (per person) is: 7 Days (In a 2 weeks Sprint after removing Scrum events time, and other non work related time)
Number of Developers in the team: 6
Therefore, the Focus Factor is: 30/(6 x 7) = 0.71
This Focus Factor can now be used to forecast the amount of work for upcoming Sprint as follows:
Let us consider there are only 5 members are available in the next Sprint, then the forecast for the next Sprint is: Focus Factor * Capacity:
0.71 * 5 x 7 = Approximately 25 Story points
How to forecast for the very first Sprint?
As there will be no historical data for the first Sprint, let the team go with their gut feeling to decide how much work they can pull into the Sprint Backlog. In this case it may lead to below two scenarios:
- Complete the selected work early: Let the Developers and Product Owner collaborate and take some additional work which will help to improve the Product value.
- Unable to complete all the work selected: Move the incomplete items back to the Product Backlog.
In either of the cases, it should be discussed in the Sprint Retrospective to find the root causes of the scenario and to learn what can be improved.
The Developers and Product Owner can take below guidelines for the first Sprint:
- Let the top few items be very clear and smaller
- All clarifications need to be addressed
- Create detailed tasks for each of the top few Product Backlog Items
- Let the Developers estimate each task in less than or equal to 6 hours
- Let the Developers calculate the available capacity of the Sprint
- See how many Product Backlog Items can be pulled to fill the available capacity as per the capacity hours and the sum of the total hours estimated for the Product Backlog Items
Even though this approach helps you to forecast the amount of work for a sprint, do not ignore the inspect and adapt approach. Scrum is all about continuous improvement with inspecting and adapting. So use Sprint Retrospective to brainstorm how to improve estimation, selecting the right amount of work into the Sprint, how to optimize the tools, practices and processes to get better.
We provide practical scenarios and real time examples in our Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO) workshops to understand the Agile and Scrum concepts. So if you are interested you can check our calendar at: at: https://www.learnovative.com/training-calender/
