dinsdag 26 december 2017

Magic estimation

Barry Overeeen describes a method for estimating a large number of Program Backlog Items (PBI’s) called “magic estimation”. Last week I facilitated a workshop for a project for my current employer with this method and I’d liked to share my findings with you. Before sharing the findings, I’d like to describe the method as I employed it.

Preparation:
  • The product owner planned the meeting, and I asked him to prepare the session by making one sheet for every user story. I mailed him a MS word file with the layout.
  • The meeting had been scheduled to start at 11 o clock.
  • I printed the poker numbers 0, ½, 1, 2, 3, 5, 8, 13, 20 and 40 on A4 sheets and spread them out along the wall, as well as a sheet marked "?" for items which were not clear.
  • I provided for white board markers in 4 different colors.
  • I made a planning for the one hour session:
    • introduction 3 minutes,
    • round 1 10 minutes,
    • explanation by product owner 15 minutes
    • round 2 15 minutes
    • Discussion of large differences 10 minutes
    • Round 3: 5 minutes

Two things went completely wrong. First, the product owner had not prepared a document with all the user stories as I had requested by mail. Probably my fault, I should not just have mailed him, but also called him. He did had set up a separate meeting with me 1 hour ahead of the estimation workshop (excellent idea), but due to train problems he arrived 15 minutes late. He did have a product backlog, but this was not entirely up to date. In the end he had just 9 user stories to estimate. Problematic was that these items were not entirely clear.
Second, management had scheduled a two hour meeting just before our estimation workshop. They failed to finish their meeting in time. As everybody badly needed a coffee break, after 2 ¼ hours, we started nearly half an hour late.

Round 1:
I explained the 6 team members the rules for round 1:
  • One existing user story, which they were building, was designated as a 5 point references story.
  • There is a stack of PBI’s, physically as A4 sheets.
  • Participants were to pick one sheet at a time, estimate it in silence, without discussion, write down their estimate on the sheet in the field “round 1” and put the sheet down at the appropriate poker points sheet.
  • I assigned colors: designer green, developer black, tester blue. This team was not really t-shaped, so I wanted to be sure that at least two disciplines had a say on the estimate.
  • Anything that was not clear, was to go onto the ? mark stack

Round 2:
After the explanation of the questions by the product owner, and I gave instructions for round 2:
  • Again work without discussion
  • Check the work of others, especially that of other disciplines;
  • If you have a different estimate, write your estimate in the “Round 2” box and move the sheet to the appropriate stack.
  • Sheets were allowed to go to the ? stack.
I did not apply the rule that an item could not be moved more than once. Participants assumed that each discipline checked every item at least once, which I allowed. Two new items were moved to the question mark stack.
Most items had just a small difference. These were given to the product owner.

The product owner explained them, and the team preferred to continue after lunch.

After lunch we had sort discussion on the remaining PBI’s. The people with the most and least point for each item explained their motives and we agreed on a new estimate.


I found a number of pitfalls with this method:
  • PBI’s are not clear enough. This translates in fair amounts of time for the product owner to explain.
  • PBI not well prepared by product owner;
  • Developers play on safe. Developers know better than anyone else that programming takes more time than expected, and never believe any statement that they will not be held responsible for the estimate they make.
  • Developers put everything on “not clear”;
  • In depth discussions during clarification by product owner.
  • Participants taking sheets form the stack may result in situations where some team members pick up more sheets than others. Dividing sheets among the team members is probably better.
Something I had not foreseen, was that people noted risks. We noted these risks on the sheets.

Reactions by the team were rather positive.

Geen opmerkingen:

Een reactie posten