So, Sprint 5 came to an end yesterday and we did the usual review/retrospective morning, followed by lunch out at Yo Sushi and an afternoon of planning Sprint 6.

This sprint, we:

1. used our release plan to consciously reduce the number of projects we were simultaneously working on in the sprint, to see if less context switching improved our efficiency;
2. planned in a quantity of work which we knew to be achievable for the development team: in previous sprints we'd deliberately overcommitted ourselves across the board, mindful of the sheer quantity of work we have on;
3. had a few guys working on QA and bug-fixes for a large project we have on. Instead of estimating individual bugs and placing them up on the board on index cards we met every morning, pulled a days worth of bugs off our TODO list and estimated them there and then. The idea was to keep track of the quantity of estimated work completed without having to up-front estimate every bug;

And the result? We seemed to have worked more efficiently; the pair working on one of our two development projects finished ahead of schedule and were able to help out with the other project. According to pure calculations of estimated hours worked vs available hours, the efficiency of our development team doubled. I certainly believe that some of efficiency was down to tackling large numbers of small bugs (individually estimated at no less than an hour each and therefore adding up to more time than they actually took); but even discounting this and considering work outside this project, we'd improved considerably.

I look forward to measuring how well we do next sprint when we're tracking work in the larger chunks which are more traditional for us.

Things we learned this time around or have questions over:

1. Grouping many small bugs into single stories by theme (e.g. bundling 10 cosmetic issues affecting the Nokia 6230i) would seem to make more sense than considering them separately. Doh, I know - but still, we know it now;
2. I'm not convinced we understand how to plan design alongside development (so far the two have been somewhat separated in our scheduling). Talking to Nick today, we're not sure anyone does, mind;
3. Quite a few of us feel ambivalent about the value of the review meeting, where work from the last 2 weeks is demonstrated. I wonder whether we shouldn't invite actual customers down for this meeting - it might give it a little more focus, and who knows: perhaps getting them and the guys doing the work round the table might prove fruitful?

This post doesn't summarise everything we covered, of course - but hopefully it's useful if you're interested in this sort of thing.