During the talk estimating/sprint size and client trust became a significant part of the discussion. A number of people had issues with picking an amount of work and suggesting that that amount of work should be concrete for the sprint. I mentioned a few ways of minimising or accepting this and there are probably many other methods:
- Set stretch targets at sprint planning by putting some targets in the sprint at the bottom of the sprint backlog. This way there's something to do if you run out, they should only be done if you really finish the other tasks and there's no penalty for not reaching them.
- Regardless of having slightly less work, there's almost always something else for developers to be doing. From refactoring time to working on side projects there's never likely to be a shortage of work.
- Clients are going to be happy with consistent work and meeting the goals they've started with. If velocity needs to change that should be worked out before the sprint.
- Developers are most likely going to be happier if rules agreed on at the beginning of the process are kept throughout, changing things at odd times is likely to have odd flow on effects.
- Any change to these rules can be easily addressed according to team desires during the retrospectives and planning for the next sprint.
The talk also spawned a talk on Kanban a project management system with some interesting properties that I might blog about sometime(it also has inbuilt support in cucumber).