Last week was a tough one – my fellow scrum masters & I had to get seven scrum teams through their reviews, retrospectives and planning sessions. There’s a lot of debate over what can be done better next time, which is good – there’s lots of room for improvement and I think addressing just a few key things will make a big difference.
For those not familiar with these meetings, I should explain a little about each of the “sessions” I mentioned above:
- Review: at the end of an iteration (aka sprint), the team demonstrate their work to the customer. In our case we also walk through our Definition of Done (a checklist of things which have to be completed, e.g. unit test coverage, documentation) and end with the customer declaring whether our User Story* is done or not. (*Yes, I can see this list needs to grow!)
- Retrospective: the team looks at two questions: What went well? and What needs improvement? – the aim is to identify new things we’ve tried which worked and therefore we want to repeat, as well as identifying things which need to be addressed in order for the team (or project) to perform better. Some recent examples are pair programming (went well but we need to accomodate the additional time required when we’re planning) and quite a few environment issues (e.g. development tools, central build). The team prioritise the areas for improvement and then we discuss them, creating an action plan which may require me (as the scrum master) to escalate items.
- Planning: the team break down the tasks required to complete their goal(s) and estimate them; we use Ideal Hours, which is an uninterrupted hour and therefore may span a longer elapsed time. As a guide we compare the total estimate effort to the team’s capacity (how many hours can the team members commit to these tasks) and, if it looks reasonable, the team commit (to the customer) to deliver the User Story/Stories at the end of the iteration.
So what’s a User Story? Well, if a “traditional” project manager isn’t already freaked out by everything so far, this is sure to push them over the edge! Instead of detailed requirements documentation, the customer create a User Story which is really just a start point for a discussion with the scrum team. It can be something as vague as “As a user, I can log on to the system”. The aim is get the team and the customer talking and drawing – it’s only when this happens that both parties really start to understand each other. A customer won’t (normally) understand what’s possible, and so doesn’t know how much to ask for / expect from the team. Equally the team don’t (usually) have the business knowledge – techies tend to think about how something can be implemented, not why the customer / end user wants it or how they’ll use it.
I first encountered User Stories only a few months ago and I think it’s brilliant – the more we can get everyone to talk then the better we’ll understand each other. Writing reams of documentation doesn’t help anyone (unless you’re selling us the paper!) because it takes much longer to transfer the information between the parties, and frequently the assumption is that the documentation is complete – if it’s not written down then it’s not important (or is out of scope, etc.) and therefore we’ll do exactly what’s written down and no more.
So anyway, it was a long week and unfortunately some of those sessions spilled over in to this week, but the end is in sight … until we start this all over again in a couple of weeks!