How to calculate number of Sprints required
Hello everybody,
Our Team is currently working in the 3rd sprint (each sprint is 2 weeks) and our velocity is roughly 10 as of now. Too early to calculate velocity at this stage.
We have quite a few PBIs in our Product Backlog which are still not estimated even at higher level.
If we are asked during the Sprint Review how many more sprints will the Project require, how can we answer this question.
Any guidance will be highly appreciated, thanks in advance.
This is a non-trivial, perhaps even impossible, problem.
First, you need to define what it means to have this project complete. One possible definition would involve completing all of the work in the Product Backlog. However, that neglects that fact that the Product Backlog is highly dynamic. Changes in the environment as well as experiences of the stakeholders as they use the product will cause the Product Backlog to change - some items will be added, others maybe removed, and more details may emerge about others. Any discussion about the Product Backlog will need to be with respect to the current state of the Product Backlog, since the state based on future changes is unknown.
If you make the assumption that the Product Backlog is stable or that your estimate of completion is based on the current state of the Product Backlog, you have to deal with the lack of refinement for some items. Refinement not only adds estimates to items, but may reveal previously-unknown work and result in larger Product Backlog Items being broken down into multiple smaller Product Backlog Items. Regardless of the method of forecasting, not knowing the number or size of Product Backlog Items will make any discussion of the far future very difficult.
I've tended to see two ways of trying to forecast the far-future like this - velocity and flow metrics. However, both are sensitive to changes in the team's knowledge and experience, team workflow and Definition of Done, and capacity, among other factors. As the team learns and builds experience in the domain and with the tools, they tend to work faster. Stricter quality measures may slow the team down (at least at first) but result in higher quality products. Team absences can be a huge negative impact on velocity. Even if you were to refine and estimate everything in your Product Backlog, these factors can can impact how quickly work flows through the system.
I would tend to look at the flow metrics, since that is based on actual completion data rather than estimates or guesses about how long things will take. However, it still won't account for changes in the team and team's way of working, especially as you get several Sprints out.
My recommendation would be to understand why stakeholders need to know how many Sprints the effort will require. Find ways to frequently deliver usable value to the stakeholders, get feedback, and act on that feedback. There are better ways to help stakeholders maximize their value and reduce their costs than vague and undefined guesses about what the future holds.
The simple answer is you can't. I'd also question the intent of being asked this in the first place by whoever raised it.
I'd perhaps approach someone asking this question and explain the principle of the cone of uncertainty.
"You are asking for an approximation of completeness when I know precisely the least about what is required".
It's like asking someone what they are doing tomorrow or next year...
The premise of the question also implies the scope is fixed. If that is the case for the entire 'project', then your situation is not complex and Scrum (probably) isn't the right framework.
I echo all of the previous answers. There is a lot of uncertainty and potential change that will make this extremely difficult.
I have suggested this many times in similar conversations, so I'll do it again.
Two books written by Daniel S. Vacanti.
The first book helps you understand metrics that can help your team's work more predictable. Then when you become more predictable, the second book will help you use that predictability to forecast. Read them in order. The second is not helpful until you have obtained the predictability from the first book.
If we are asked during the Sprint Review how many more sprints will the Project require, how can we answer this question.
Zero.
You're in the Sprint Review. In Scrum each Sprint is a project and the project is over. Every Sprint ought to produce at least one Done and immediately usable increment of work, and we conduct each of them as if it was potentially our last. If this answer is deemed to be unsatisfactory, find out why.
Thanks everyone for your inputs, I am now prepared to answer such questions if they popup.