Finish All Work Every Iteration

“After I’ve finished this story, I’ll pick up story #1354”.  Trouble is that #1354 is a 5-point story that will take two people two days to complete…and there are only two days left on the iteration.

This is known in our process as a ‘hip-pocket’ – a story which hadn’t been committed to, but was next in the priority queue and so would be ‘pulled in’ to the iteration and worked on.  We’ve considered this method a good one to keep the team productive when happenstancely they finish up on the committed stories early.  After all we wouldn’t want the teams to be idle, would we?

The problem with this of course, is that the story cannot be finished by the end of the iteration, then two things happen:

1. The story does not get finished at the start of the next iteration because the Product Owner decides that the next body of work is more important than finishing this, but now, low priority story.  The effort put into to, in order to ‘stay productive’ is now therefore ‘wasted effort’.  Even if the story is finished a month or so later, it is still waste because it is sitting on the shelf as ‘work-in-progress, when something of more immediate value could have been produced.
2. The story is held over and committed to in the next iteration.  This is fine if that is exactly what the Product Owner wanted – but I suggest it takes a real discipline for a Product Owner to walk away from ‘almost finished’ work (and all work in progress is always ‘almost finished’ of course!  So by starting the work in the previous iteration, the design team has in effect limited the choice of the Product Owner, and forced them into a potentially sub-optimal prioritization.

Both these outcomes have one thing in common: waste!  So what is intended as a productivity booster actually is nothing of the sort.  The team can always do work which is not in danger of being wasted and that won’t constrain the Business’ ability to change its mind (re-prioritize) at the end of each iteration or development period.  For example they can:

• help other team members finish their stories
• write some additional test cases
• investigate bugs