My understanding of Scrum is that I determine the work my team can take on in the next sprint by averaging the number of completed points for the past several sprints.
This is an average, so if history repeats itself, this sprint it is 50% likely that we are taking on too few story points, and 50% likely that we are taking on too many story points.
In the case we have taken on too many story points we could:
-
Fail to complete the sprint. This means we will fail to meet our sprint commitment half the time.
-
Work extra to catch up. The problem is that this ratchets only one way. We will accomplish the sprint, and the number of story points completed will reflect that. Since we always finish, over time, our average will trend upward to the point where we are always accomplishing a large number of story points and staying late.
Is my understanding of average velocity and sprint commitments correct?
If so, what should we do for the 50% of sprints where we are behind average?
If not, what have I gotten wrong?
Best Answer
Yeah, you have the gist of it.
The thing you overlooked is that story points are the things you get done. It is nigh impossible for everyone to work on stories right up to the end of the sprint. If you're doing things right, most of your developers will be "idle" for a few days while the stories are being tested (and your testers in the middle of the sprint as development is in full swing).
I put idle in quotes because your developers aren't sitting around watching cat videos, they're fixing bugs, polishing up some code/unit tests, adding some documentation around processes, thinking about the design for stories in the backlog or one of the other dozens of useful things that a development team can benefit from but don't fit well into a story.
So while you will over-guess 50% of the time and under-guess 50% of the time, that doesn't mean you're going to fail the sprint or have to work overtime. It means that you won't have quite as much time to do this miscellaneous work (unless you really miss your estimates). But that's not a big deal, since the miscellaneous work isn't time sensitive, and things will even out in the long run.