I remember Alistair Cockburn’s advice on conducting an iteration review (Agile Software Development 2nd Ed).. I fish out that section. Iteration review.. its called Reflection Workshops.. here it is …
Iteration Reviews/Reflection workshops are great coz they give you a breather at the end of an iteration and double up as introspection / discussion time. To improve and get better. Although you should ‘stop-the-line’ as soon as any problem surfaces, end-of-iteration reviews are more relaxed and can serve as grounds for open-discussion Identify problems or ‘broken-windows’ areas that may become troublesome soon, find options/alternatives and plan on tackling them. Large-Refactoring may often lose out to new customer requested features on the priority chain .. But if you can convince yourself on why they need to be done now.. you can more or less persuade the customer to add that to the next iteration’s bucket.
- Reflect on Product: The customer that is Me, would like the ability to track expenses preferable with categorized reports in the product soon as that would make it useful. Currently it’s just tracking inflows. So we need to build in tracking expenses and a running balance at the minimum in the next iteration or two.
- Reflect on Progress: We spent the first half trying to get Fitnesse and Rails to run. The second half was when the wheels started to turn. We managed to complete one story with its acceptance tests all passing. We also refined the UI quite a bit from its scaffolding origins. I think we should go faster in this iteration but still we will keep a conservative
- Reflect on Process: Let’s look at our burndown chart.
I think we’re good with the process. Its working out well. Only thing from the iteration planning p.o.v., we see that we were flat for an extended period of time in the center – the implementation part. I think we should consider splitting CR into smaller tasks on the CRUD lines. It was annoying to see ‘no progress’ for over 2 days ; even though I was chipping away at it. Also there were some tasks that were not needed like CIS, Push Button releases. We need to cut down on tasks that we can do without. As the lean books say – Be LEAN and MEAN with unwanted complexity!! WRITE LESS CODE!
This format from the book is quick-n-easy in a BigVisibleChart kind of way