On a recent visit, I was asked to help them plan a new release. They had a bunch of user stories, a wireframe to help show where they fitted in to the plan and also a knowledgeable product owner in the room too. The developers, influenced by a charismatic and confident architect, decided they wanted to get a high-level estimate of the backlog they had been presented with and then ‘get back to work’. They didn’t want to be stuck in another meeting all day.
So, I asked the question: “what benefit will this approach bring?”
My reasoning for this is my experience tells me that high levels estimates set the wrong expectations, waste time in the long run and cause friction from the start. So, why do I say that?
Requirements aren’t like microchips, which get more complex as they get smaller. Requirements get easier to understand as they get smaller. The better understood they are the more accurate the estimate will be. We can see this simply with the following example.
What is the volume of a pea? About 2/3 cubic centimetre.
Whet is the volume of a tennis ball? About 200 cubic centimetres.
What is the volume of the moon? I can’t even make a realistic guess.
So, I persuaded the team to use a technique from Behaviour Driven Development (BDD). I asked them to write only the scenario headings for each story in order to promote discussion and help us understand what a user would expect to do for each story written. It had a fascinating effect.
Firstly, discussion was focussed, short and effective. In just one hour and twenty minutes we’d talked about all 25 stories in the release. As a team we understood them better. We’d also realised we had missed a few stories out. So we wrote them and added them in. Additionally, having learned more about the requirements, as a group, we were able to happily re-prioritise some stories to the next release.
At this stage the team had a really good idea of what they were faced with.
So we took a working break and left the meeting room to go to a nearby coffee shop, where we did some story pointing. The team story pointed all 30 stories in 25 minutes. Considering the week before they had spent 40 minutes just estimating one story this was a major success.
So what was the overall result?
1) A better understood backlog.
2) A happier team, who saw real value in the exercise for them.
3) A Product Owner with expectations better set.
4) Less time spent in meetings.
5) Missing requirements found and added to the backlog.
6) Better, shared understanding of the work that the team will have to deliver.
7) A business more confident that it’s teams can deliver.
Most notably though, the rumours of what we had done spread throughout the organisation and we have since coached the other teams to do this themselves without the need ongoing support.
