Change the Scrum Guide™
What is Scrum?
Definition of Done
Scrum and Agile Webcasts
Professional Scrum Foundations™
PSF Subject Areas
Professional Scrum Master™
PSM Subject Areas
Professional Scrum Product Owner™
PSPO Subject Areas
Professional Scrum Developer™
PSD Subject Areas
Scrum Open Assessment
Developer Open Assessment
Professional Scrum Master™ Assessments
PSM I Assessment
PSM II Assessment
Professional Scrum Product Owner™ Assessments
PSPO I Assessment
PSPO II Assessment
Professional Scrum Developer™ Assessments
PSD I Assessment
Work With Us
By posting to our forums you are agreeing to the
Dev. Team: workload versus capacity
Last Post 11 Feb 2014 07:05 AM by Bhuvan Misra. 4 Replies.
Most Recent First
You are not authorized to post a reply.
08 Feb 2014 10:22 AM
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?
08 Feb 2014 11:27 AM
> 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.
08 Feb 2014 12:29 PM
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.”
09 Feb 2014 07:44 AM
Thank you very much!
11 Feb 2014 07:05 AM
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.
You are not authorized to post a reply.