Skip to main content

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?

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.