Velocity in Agile is a key measuring unit of the amount of work a Scrum Team can complete in a Sprint. It is calculated by summing up the total story points of all the fully “done” user stories. Approximately the last 3 sprint’s velocity average is used as a metric to measure the team velocity of the future Sprint. But this is a relative estimate and need not be accurate and can vary because of many other factors.
Capacity is an estimated forecast of the total number of hours a Team is available that can work to deliver efforts in a Sprint. It is calculated keeping in mind these factors like anticipated holidays, team member leave plans, their other work commitment, training, and meetings, etc.
Scrum teams often face challenges when they need to commit to the number of user stories that they can deliver in a sprint during Sprint planning. We can say the number of team members multiplied by the total time they work in hours per day multiplied by the number of days in the sprint. Although this gives the team’s capacity, in order to get the “real” capacity, we must consider the focus factor. The focus factor indicates the capability of the team that can stay focused on the sprint goals. The total capacity has to be multiplied by the focus factor value to get the total capacity of the team.
For example, usually, the focus factor will be between 0.6 – 0.8 with the assumption that the team would work some X number of hours per day (say, 6-6.5 hours per day) and so the focus factor is 0.6. The focus factor is a ratio value calculated by dividing the team’s capacity (after reducing unavailable hours) by the total Team’s capacity. This capacity planning helps in defining the Sprint Backlog items based on Team’s availability and the prioritised Product Backlog Items.
In the Agile world, the Focus factor allows you to calculate the productivity of a team based on the number of deliverables possible with the current availability of the resources in a Sprint iteration. This number is arrived at by using the capacity (excluding holidays, leaves, meetings, training time, etc) and velocity of the development team.
Focus Factor = Sprint Velocity / Available Team Capacity (in man days)
A low focus factor indicates that the team is having bottlenecks in completing their work, and hence the previous team velocity is less. The focus factor cannot be 100% for a team. But in the ideal case, we can consider the focus factor to be 60-70% for a team.
The Agile estimation uses a top-down approach that gives a definite direction to the product development. The team members provide estimation based on the planned duration of the project, or effort required to complete the work. Based on the preliminary estimation, the teams drill down further into task level and estimate them more precisely.
Planning poker (also called as Scrum poker) is a consensus-based, gamified technique based on Delphi method using a deck of cards to estimate effort using story points (or relative size) of user stories in Scrum. It combines three estimation techniques called Wideband Delphi Technique, Analogous Estimation, and Estimation using Work Breakdown System.
In this technique, the developers pick a numbered card (which has Fibonacci values such as 1,2,3,5,8,13,20,40…) to estimate one Product Backlog item at a time. If the estimation varies hugely across the team members, then the process is repeated until the Team arrives at the consensus. The same steps are carried out for all the product backlog items to estimate the User Stories.
The Planning Poker may take more time to estimate a large bunch of Product Backlog items. However, this may give more accurate estimates.
Affinity Estimation is a technique commonly used by Agile Teams which can leverage many types of relative estimation techniques including T shirt sizing (XS, S, M, L, XL, XXL), Fibonacci sequence (1, 2, 3, 5, 8, 13, 21…) based story points, or other scales. This helps to estimate (in terms of story points) quickly and many user stories easily. The accuracy of this method is less compared to Planning Poker technique.
The Idea Time estimation is a commonly used estimation techniques in the waterfall projects than Agile projects. It is an alternate to story points technique and more easy to use than story points. Developers and Testers give estimates independently without talking to each other and considering the impact on each other function. “Ideal Time” Estimating is the time we think it would take to complete the work optimistically assuming that everything goes well.
The T-shirt sizing is a quick and easy relative sizing estimation technique used by the Scrum teams. The story is estimated in terms of Extra-small, Small, Medium, Large, Extra-large. This User Story estimation session doesn’t focus on absolute time or effort, rather emphasises evaluating in relatively sized buckets. It is also a great way to get accustomed to relative estimation because of its simplicity.
Lead time measures the time elapsed between the request from the customer (user story creation) and delivery of value. It is the end-to-end process from the customer’s perspective, starting from the requirement to its fulfillment.
Cycle time measures the elapsed time between the time when the work starts (user story) and it is ready for delivery. In other words, Cycle time gives us the duration of time to complete a work item.