My boss has been reminding me to watch this screencast about Agile Best Practices by Jay McGavren for a couple of months now, and finally yesterday I did.

I’d really recommend it. The examples used in the first section on Sprint Planning could almost be taken from some of our recent sprints. Lets review how we get on…

Sprint Planning

Lock Requirements during Sprints

No additional stories should be added to a sprint once it has started. This way we know exactly what to expect to see at the end of the sprint. I am really guilty of not sticking to this. I think perhaps because we haven’t thought out the requirements enough before hand, something will come up mid sprint, and I’ll think “yes we have to do that or it won’t be useful” or “that sounds like a good idea” and it gets added. But this increases the risk that we won’t finish the stories we did plan. And it’s quite likely we won’t think out the new requirement properly either.

Time boxing

Sprints should have a fixed length, so everyone knows that the results will be available on a certain date. We need to get better at estimating the stories which can go in a sprint, and sticking to a fixed time frame. That means that everyone knows what they can expect to see on a certain date. We let sprints go on until we’ve finished all stories, which means (see above) sometimes extra stories get added, and we don’t have a fixed date on which to demo the results. By sticking to fixed time boxing, we’d be able to identify problems with the stories in the sprint straight away, before building anything else on top of them.

Only the team estimates

This means that the people who will be doing the work should estimate how long it will take, as they have a unique insight into the potential obstacles. On the one hand, we’re not too bad on this – it is generally only the team that estimates. However, I would guess we’re pretty bad at estimating. Things seem to take longer than planned. I think we need to put more effort into the planning phase to identify the stories and estimates, and look back at where we were out, so we get better.

Product Owner Availability

The product owner should always be available, as they have unique domain knowledge and will be needed for clarification of requirements during estimation. The screen cast suggests this should be a full time job, so that other work can’t take priority. Although that’s not feasible for us, the product owner must be identified and a proportion of their time allocated to the project. Sometimes we don’t include a product owner in our planning sessions because we think we know what the requirements are, but this risks us missing key operational details.

Feedback

Demo every Sprint

Demonstrating the results of a Sprint is the best way to show people what they are getting, and removes the chance for any misunderstanding. It is much more effective than expecting people to read a detailed specification. We generally demo when we’re ready to release, which is too late if we’ve built on top of an invalid interpretation. So far we’ve not had any major set backs because of this, but that doesn’t mean it won’t happen! This goes back to product owner availability – if people are busy it is sometimes hard to interrupt them – if being a product owner is a key part of someone’s role, it would not be an interruption.

Testing

Test at Development time

Testing at the same time as development means bugs can be discovered when they are easy to fix. We’re pretty good at this! We don’t merge to our development branch without good code coverage. Now we’re moving into apps with a UI, such as grails based tools, we could probably improve on automated testing of the UI. But in general, test driven development is how we work.

Shared definition of ‘Done’

Everyone should have the same definition for when a story is ‘done’, to avoid miscommunication. I think we’re ok on this. As above, ‘done’ means coded and tested.

Conclusion

It’s hard sometimes to stick to agile best practices – some of our team split time between development and other tasks, which makes planning more difficult. And we work on a number of smaller projects, so we’re not constantly moving in one direction on one project. However, we could still improve our sprint planning a lot by sticking to the 4 rules identified in the screen cast. We’re going to try this out for the next sprint, and see how we get on…