Tuesday, August 12, 2008

The Value of Collaborative Estimation

This presentation given by Mitch Lacey was essentially a case study of a team's problems with its scrum implementation and how this was eventually solved by making a few changes and introducing new practices.

My post will essentially be a summary of the case study highlighting some of the points I found to be the most relevant for any team who might want to review their scrum implementation to make it better.

One of the things that I found very interesting in this presentation was the realization of the fact that it is not because a team performs a scrum that it magically develop better and instantly deliver quality. Like any process and practices, there is a need to perform retrospectives to bring up the question of "what can be done better?" This question alone is an instigator of something people aren't always keen on doing and that is to CHANGE.

Something I've learned during this week long conference it that change is good, and when trying something such as scrum that doesn't work as well as it should (as described in the books) then change is something that should be introduced to help achieve the desired results.

Moving on to the case study; the issues experienced by the team were:
  • The business unit (BU) owners needed realistic estimates
  • The BU owners needed a shippable product
  • After each sprint, the numbers of "Not Started" and "In Progress" tasks were significant
  • The team just wasn't delivering
This basically broke the trust between the team and management. At some point in time, a consultant was brought in to analyze the situation as the following items were deemed to be a constant cause of these problems:
  • The team had no clear definition of "done"
  • There were too many open tasks per person
  • There was no standard demo meeting format
Other causes we identified but these weren't a constant factor:
  • The subject matter experts (SME) didn't participate in performing sprint tasks
  • The SME did all the estimation for the team
  • The sprints were too long
The following list of solutions were proposed and implemented immediately:
  1. Have all team members participates in estimating the sprint backlog by using planning poker
  2. Write a clear and comprehensive definition of DONE
  3. Reduce the amount of open tasks per person to no more than 2 or 3
  4. Formalize a demo meeting
  5. Reduce the sprint length from 1 month to 2 weeks
Planning Poker

Using planning poker instead of the usual guesswork involved for estimating is a recommended technique for scrum teams. It gets the team members more involved and produces overall more accurate estimates that allows the team to deliver value in a more predictable way. I'll put up a post later which explains en greater detail how planning poker can be used to estimate a sprint backlog.

Define "Done"

Simply having a definition of the word "done" for the team can have some beneficial effects. For example:
  • It provides clear communications to the stakeholders
  • It drives down risk
  • It bonds the team members
Reduce the Amount of Open Tasks

Doing too many tasks at once introduces context switching. Context switching is counter productive hence focusing your daily work on a minimum amount of tasks will reduce this effect. If you need some convincing on this subject, try the following experiment:

Ask a colleague to have a race with you. You will each need a pen and a piece of paper. The objective if to write three series in columns. The first column will be the numbers 1, 2, 3, 4, 5, 6, 7, 8, 9, 10. The second columns will be the letters A, B, C, D, E, F, G, H, I, J. The third column will be the roman numerals I, II, III, IV, V, VI, VII, VIII, IX, X. Your colleague must write the series from top to bottom starting with the numbers, then the letters, then the Roman numeral. You must write the series from left to right, context switching from number, to letter and to Roman numeral. You should both start at the same time. See then who finishes faster.

Demo Meeting

The demo meeting is meant to demonstrate the delivered value to the product owner. This "scrum ritual" should be formal and well defined.

Sprint Length

The basic idea behind this is quite simple; by reducing the sprint length the estimates become more accurate. An estimation of what can be done over a two week period will be more accurate than that of what can be done over a one month period. Mitch posed used the following question to demonstrate this point: “If I ask you today what you will be doing in one month and then in two weeks, with which answer will you have the highest level of confidence with?”

The introduction of these changes within the team has had significant benefits and I am convinced that such changes could benefit others too. I recommend you read the full presentation and see the numbers for yourself. It is available at the following address:


No comments: