Dev. Team: workload versus capacity

> 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.

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.”

Mehdi

Thank you very much!

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.

--Bhuvan.