Respect the Team's Capacity

Many times I have watched scrum teams ignore their historic capacity and proceed to add more work than they can possibly do to a sprint. Sometimes this is because a manager insists they include "stretch goals" in the sprint. Bad idea! Other times it's coming from the product owner who is being pressed by the business to deliver multiple features in a short time frame. This simply won't work.

If you have a stable scrum team, made up of regular team members who do not switch out to other teams or work, you can determine their capacity by watching their velocity. If they commit to 100 story points of work but consistently deliver around 70 story points, then you have your capacity. The only way to increase their capacity is to increase the team size, which itself presents problems.

When you add members to an established team, two things happen. First, the team overall can slow down as the new members figure things out and the team relearns how to work together. Second, if too many members are added (9 is really the maximum for a healthy scrum team, in my estimation) then ceremonies will become unwieldy. The attempt to speed up the team can suffer, at least in the short term. 

The wise path is to introduce new members only if a short-term slowdown is acceptable, and to respect the team's capacity otherwise. There's no use adding more work than can be done, if at the sprint close you find that there were points left over unaccomplished. The optimism of sprint planning must be tempered by facts.