Skip to main content

Dev. Team: workload versus capacity

Last post 08:05 am February 11, 2014 by Bhuvan Misra
4 replies
11:22 am February 8, 2014

Hi again,
something crossed my mind:
during the Sprint Planning the Dev. Team decides about their own workload for the next Sprint. The Dev. Team estimates the PBI's, but also get input from the PO about what should be done.
It may be unrealistic, but how should the Dev. Team act, if the workload for one Sprint exceeds the capacity? I know, that the workload may me renegotiated with the PO. But what's about other solutions, e.g. recruting of additional Dev. Team members? Or beginning the Sprint known that the workload definitely will be unfinished?


12:27 pm February 8, 2014

> It may be unrealistic, but how should the Dev.
> Team act, if the workload for one Sprint exceeds the capacity?

The Development Team should and must not accept work into a Sprint Backlog if they don't believe they can realistically complete it within the Sprint timebox.

This is a consideration that is also affected by the Definition of Done, the cited Sprint Goal, the need to potentially support actual release including any necessary integration with other teams' work, and other factors.

> But what's about other solutions, e.g.
> recruting of additional Dev. Team members?

Adding further Development Team members changes the Scrum Team, and can therefore introduce uncertainty regarding the next sprint forecast. It should not be seen as an *immediate* remedy for low throughput or indeed any other Scrum Team problem.

01:29 pm February 8, 2014

A Scrum Team has four stages is its life cycle: Forming, Storming, Norming, and Performing. A performed team works smoothly and has almost a constant high velocity (story points done in a sprint). That helps to estimate more accurately. But at the beginning the team are busy to improve their infrastructure and optimize their work process, consequently the velocity is low. They will eventually be faster when the same team works longer with each other and if they use agile engineering practices consistently. That means they should be aware not committing more than their capacity, in order to avoid comprising their DoD ,reducing of the quality and causing technical debt.
One of Scrum Master’s most important responsibilities is to help the new formed team to estimated realistically and advise PO and Dev. Team against push/pulling too much. “The Development Team may also invite other people to attend [Sprint planning Meeting] in order to provide technical or domain advice.”
One of the best methods of estimation for unexperienced teams is the comparison with other Scrum project in the similar situations.

As you yourself mentioned correctly and is also described in Scrum Guide: “If the work turns out to be different than the Development Team expected, they (Dev.) collaborate with the Product Owner to negotiate the scope of Sprint Backlog within the Sprint.”

I think adding new members doesn’t help really in this situation. Again from S.Guide “Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team.”


08:44 am February 9, 2014

Thank you very much!

08:05 am February 11, 2014

The Development team must take up work within the confines of the DoD it has decided. Team’s that stick together for longer tend to be able to take more work in successive or future Sprints. Ad-hoc additions/changes to team composition per Sprint may have a negative impact on team cohesion and hence reduce Velocity. Overall, the team size must continue to be within the range suggested in the Scrum guide.


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.