Agile velocity & Estimating project duration

Introduction:

Scheduling and time management plays a vital role in projects management because time is a constraint which can affect the project scope and cost as they contain the overall goal of carrying out the project, business case and strategic objective.
In the predictive Approach, the most important output of the schedule planning is the schedule baseline, it is the output of creating WBS process, the last process in the planning schedule knowledge area, the baseline contains the duration of the overall project, and any change to that can affect the end date of the project.
In agile, which is also known as the change-driven approach, we can’t rely on a stable or robust time frame, there is no real baseline. Literally, anything can change at any time, so we provide the viable deliverable in a certain interval, known as increment or iteration. Let us discuss that in more detail.

Velocity:

Because of the changing nature of Agile deliverables or features, it is difficult to estimate the exact duration of the project, this fact can become a real issue for customers, because when you invest in a project, you will simply ask the contractor, about the exact time to receive service, product and result? To answer that we use the estimating term known as velocity. We can calculate how long a project could take to complete, by understanding how much work, the self-organised team can complete, per a timebox.
From Cambridge, dictionary velocity is the speed at which something happens or moves, and from primary school, we knew the velocity equation: velocity = distance/time. So, instead of distance in Agile, we estimate the units of work completed, in SCRUM it can be user stories or story points, you can also use working hours. For the time, we can put the iteration, sprint duration or our timebox such as two weeks. Consequently, the agile team velocity = story points/number of iterations.

On the other hand, dividing the total amount of story points by velocity would result in the number of iterations required to complete the SCRUM or the project, with agile time-boxed length (ex. 2 weeks), the estimated project duration can then be calculated.

Practically, we can estimate the team velocity after a few iterations (from two to four iterations), then it can be stable and used for project time planning, besides that, we can also use it for the estimation of work to be performed in each iteration.

Example:
Given the following estimates what the velocity? How many sprints remaining to complete 160 story point?

This calculation is only correct based on the stability of the number of team players, the scope of work in the product backlog, and the complexity of remaining work.

conclusion
Agile team velocity is also used as a quality indicator. Because during the project, you can recalculate your team velocity, and it can get higher or lower, these trend reveals the team performance. For example, a decrease in team velocity can give us an indicator of the difficulty of the feature the team coding, so we can divide the features of the backlog into more manageable features to increase the yield. Conversely, increasing team velocity can indicate require deeper investigation of deliverable quality, to avoid creep and bugs.