Sep 21, 2010

The missing ceremony

It’s been a while since I got my act together and posted here – this seems to coincide with the purchase of my android and a preference for posting expletives to twitter.

So I’m about to embark on my third scrum project and I  thought it a good opportunity to reflect on my personal experience on those first two projects. In particular I wanted to briefly rant about what I’ve been calling the missing ceremony of SCRUM.

On my first project I acted as the Scrummaster  - On this project we were just dipping our feet in the water and I enjoyed the experience (..and the project went well). In my second project I entered the project midway and was asked to take on the Product Owner role.  I entered the team during the third Sprint, and my predecessor was still involved so I was lucky enough to act as observer for the first couple of weeks before diving straight in. There was a bit of disturbance in the team in the overlap between Sprint 3 and 4 – I was coming in as Product Owner, our Scrummaster had scheduled leave and as usual I had a boat load of other stuff on the go…anyway we committed to Sprint 4 and away we went. I began to notice that during Sprint 4 the team were having quite a few interpretation issues regarding the stories which we’d committed to. Now I believe there are two ways of looking at this issue:

1. In an ideal situation we can take a story from the backlog and have on hand all the resources and people to discuss what the story is all about, this might be a BA for example who knows the intended feature like this back of their hand and can work directly with the developer and tester to work through the story.

2. In an not so ideal situation we don’t have these resources on hand and we can ensure that we prepare the stories to such a state prior to commitment that we can avoid the unnecessary interpretation chatter.

The first approach is a well oiled machine, it takes time to mature to a scrum like this IMO. The second approach is where I directed my attention, the critical ingredients missing were a) the Scrum master to help us implement the process properly (he was away unfortunately) and b) proper preparation of  the backlog prior to the commitment. So I made an appointment with the client to do a ‘formal review’ of the backlog near the end of Sprint 4. This is essentially the missing ceremony  – its backlog grooming  - if you haven’t heard Roman Pichler speak about Agile product management then I recommend listening to this. I call it the missing ceremony because to me it seems such a crucial aspect of sprint preparation that I would now always consider making it a mandatory activity. The net result of the backlog grooming was that I had already spent time quizzing the client about the backlog before Sprint planning and I was confident that I understood the stories and that I had already covered off many of the questions that the team would ask. This meant that less questions and queries arose during planning  (which makes estimation easier), less questions were raised at the sprint kick off and most importantly less interpretation issues came up during the sprint.

Even if you do have a well oiled Scrum I still think there’s value in preparing the backlog ahead of sprint planning and I would go as far as making this a standing part of your Sprint.

2 Comments

  • I agree. This was my experience also with my first SCRUM project. It is easy to think that a user story light on detail will be fine as the detail will come in the first few days of the relevant sprint. But in reality, that did not happen. We implemented a program of undertaking design work in the sprint proceeding the sprint where the user story would most likely get built. Felt a bit like going back to waterfall, but actually provided the all team members (client and us) with a detailed understanding of the user story and meant we could get straight into the dev work when the time came. Now I have name for it – “backlog grooming”. Thanks Butch!

  • Yep there is a big emphasis in Scrum that the Product Owner is regularly visible to the team and that he knows the stories well enough to back up stories with sufficient detail. This was my argument with Peter near the beginning – before you go into Sprint Planning you need some detail around the stories otherwise the team may not understand them sufficiently to develop them.

    I think this is *assumed* in Scrum rather than enforced – if the Product Owner does not have opportunities to sit with the client and thrash things out then the stories should stay on the backlog until such a meeting has occurred. Hence it’s not really a meeting associated with a particular Sprint, more an implication of the Scrum methodology.

    The whole crux of Scrum is that the client must be involved on a regular basis, otherwise it falls apart a little bit (which is what happened when I was at EDS).

Leave a comment