Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

Forecasting work for a new team

Last post 11:26 am February 15, 2022 by Thomas Owens
2 replies
07:30 pm February 14, 2022

I am trying to come up with ideas of how to forecast work for a team before it is formed. Management is asking how many scrum teams will be needed to complete a project within 12 months. 

Currently, the project has not been approved for funding. Before funding can be approved management wants a high level assessment of the needed workload and how long it is estimated to take to complete. 

How would you go about estimating work when there is no scrum team in place to size it? Who does the estimating of the work? 

Appreciate thoughts and ideas


08:26 am February 15, 2022

Management is asking how many scrum teams will be needed to complete a project within 12 months.

A Scrum Team will complete a project in no more than one month. That's what Sprints are for. A greater leap-of-faith about a supposed project is avoided by this means, which establishes empiricism under complex conditions.

Are you satisfied that management understand this point? Have they clarified what they hope to get out of Scrum Teams, and why?


11:26 am February 15, 2022

Depending on the context in which you are working, it may not be possible to forecast or estimate work 12 months in advance. This is the specific problem that agile methods are designed to solve.

Knowing how long something will take often requires having a high amount of certainty and details about the full scope of work. Agility is built around the idea that you can't know the scope of work up-front and the understanding emerges as the work is done. By iteratively and incrementally designing the solution, stakeholder feedback can provide more visibility into what work is actually required.

If the project is very well understood and has little uncertainty or ambiguity, then you can try predictive approaches. A small number of people can analyze and model the requirements and maybe come up with an estimate that's within +/- 50-75% of actual and determine the effects of different team sizes and skill levels on that estimate.

However, very few projects have such little uncertainty or ambiguity that this approach makes sense. The best thing to do would be to identify an up-front investment and invest in a team to get started. Following an iterative and incremental approach, the team would be building a solution and demonstrating it to stakeholders, using feedback to change direction. This team can also provide information about if it makes sense to grow the team or scale to additional teams and what this would have on the schedule. The stakeholders can make the decision to stop the effort, continue as-is, or consider growing the team or scaling the number of teams on an iteration-by-iteration basis.

In order to get started, the stakeholders who have the money to fund the effort probably have some idea of what they would consider to be acceptable costs for the project. That's a good starting point. Within that amount, can you form a team for a couple of months to begin working and get more information?