Calculating upcoming sprint velocity
We are working in two week sprints cycle. My team has delivered 48 story points in previous sprint, and 50 in the recent sprint. The team was in full capacity for both the sprints and their was no holiday. Now, how can we forecast the velocity of upcoming sprint where 3 team members are on planned vacations (1 day for each), 1 Dev is unavailable for entire week and there are two Public holidays. This is just an example that I mentioned.
My concern is if there is any formula to calculate the upcoming velocity? Shall we consider Capacity-to-Velocity ratio while estimating the velocity?
Please review this thread carefully as it is fully of great insights from many professionals in regards to the use of velocity:- https://www.scrum.org/forum/scrum-forum/17203/calculating-velocity-what…
Do the team understand how the constraints you describe will impact their ability to complete work to the satisfaction of the Definition of Done?
Remember that velocity isn't just about doing stuff so points are somehow and mysteriously "delivered". Velocity is the rate at which work is Done each Sprint, so valuable and immediately usable increments are delivered.
Hi Atul, for me, velocity is more about the work realized in the past. I don’t know if you are manager, Scrum Master, Product Owner, or Developer. If anyone in a Scrum Team can estimate the impact of the constraints mentioned above, it must be de Developers. During Sprint Planning, the Developers make that forecast: the selection of work they see feasible for the upcoming Sprint, taking into account anything they find helpful, for example, vacations or velocity. The “pull” of work is an essential part of the Scrum framework. Your angle seems to come from a “push” approach. Also, the timing to make that forecast is vital. Any formula calculator at the wrong moment is not going to give you what you need. As a manager, I would look at other metrics. Velocity is a team level metric.
Note that the Scrum Guide mentions Velocity and "Story print" zero times.
When planning the Sprint, the development team will review PBIs and forecast their delivery within the sprint. The development team must be made aware of any pending holidays (and sick days - wouldn't that be nice) to be taken during the period. If the goto SQL Expert is on holiday, then that PBI point's just got a lot higher!
Using experience the team will only pick what is possible based on the skills and capability of the team within the battle. To assist, the use of Story Points and later Velocity can help plan the sprint forecast however, this is a team activity and placing too much trust in the previous Velocity can lead to over-committing within the sprint. After all, if the work was easy and Velocity the same, you wouldn't need Scrum.
As said well in the comments above, Scrum is a pull process. Where the team add in the work until they are full. With each new PBI adding to the sprint, the nay/yah should become louder.
As a Project Manager, it's possible to look at Velocity and forecast the delivery of the whole backlog, but as is the case with all roadmaps, they'd be wrong. As a Product Owner, you know what's been refined and based on history sprints you will learn where the team will start to say Nay.
I think of Velocity as a Scrum+And process, where Scrum is the Framework with some additional goodness to help with the events.
Velocity, Story Points, Sprint RoadMaps, Definition of Ready
We can't predict the future, so we forecast two weeks in a Sprint; we can't predict two weeks, so we forecast each day in the daily scrum.