Mary Poppendieck posted an excellent response to an often asked question: Should teams load iterations conservatively and return to the product owner later for additional items if done early, or queue up each iteration with a massive workload and an understanding that low priority work may not get done?
Every team I’ve worked with has this same dilemma and in the past I have advocated the latter: load up each iteration so the product owner feels like the team is really aggressively trying their best to get the most possible work done.
But Mary Poppendieck presents a compelling argument for “small batches” based on queuing theory:
“A quick look at Queuing Theory says that you get more done faster if you leave some slack. When you try to load anything (a server, a highway, a development team) to 100% capacity, everything bogs down and goes a lot slower. It is best to let a team 'pull' work from the backlog if they complete the work of an iteration early, rather then schedule work they might not finish.
Realistically, once a team has developed a track record, they are pretty good at knowing how much they can complete in an iteration (their velocity). Better that they spend a bit of spare time (should they have any) making sure the code is really 'done done': refractored, integrated, tested, documented, etc. Or how about a day of training or an "after action review"? Next iteration they can take on more work with confidence."
This assumes, of course, that your team is relatively motivated and forthright, enough so to come back and “pull” more work if an opportunity exists.
I would argue against my previously held position that a vigilant PO can detect a “slacker” team in either model, so overloading a sprint just to “keep the team honest” doesn’t quite make sense. The sometimes count-intuitive benefits of slack continue to amaze me. Thanks Mary!