Struggling with capacity in Sprint Planning
via Scrum.org Blog by Olivier Ledrz
Is your organization struggling with capacity when planning your sprints?
Your Sprint is over. Your increment is “done”, you have coded cleanly, your unit tests and integration tests are bright green, you are proud of your work. The Sprint Review is running smoothly. The Sprint Retrospective allows the team to find 1 or 2 axes of improvement without revolutionizing the world.
You follow on your Sprint Planning, identifying a friendly Sprint Goal as a target, a dozen Product Backlog items as a trajectory and a nice Sprint Backlog to get there.
Meanwhile, in the next building, your favorite users (internal employees of the company) will do some functional tests, when their daily professional obligations leave them the time.
It turns out that these functional tests make them find defects serious enough to deserve to be treated “quickly”. The Product Owner insists, perhaps a bit heavy, that patches be made from the current Sprint, strongly upsetting your Sprint Backlog or even endangering the sacrosanct Sprint Goal.
And unfortunately, this pattern is repeated Sprint after Sprint.