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.

maandag 31 juli 2017

That Guy - This Guy - an agile retrospective method

This morning we tried something new during our biweekly retrospective. The method I used was based on "That Guy - This Guy", from the book "Fun Retrospectives, by Paulo Caroli and Taina Caetano, but with a twist.

Let me describe the method in some detail before explaining my expansion.
Before starting and welcoming the participants ( I think there were about 7 of us), I drew this illustration on the whiteboard.


I explained:
"Try to recall co-workers from past teams - NOT your current team. Picture in your mind two of them. 'That guy' was terrible. The instant you get the message that you will be in the same team again as he she, you start having nightmares, you start screaming about jumping from the roof or you decide to solicit at a competitor. Instead, 'This Guy' rocks. The instant you hear you will be in the same team again, you start thinking about throwing a party, and phantasize about a promotion."
"I request you to write notes about the qualities of such a person. As for 'That Guy', plz don't mention any names. Not even a hint. And what I said about Guys, also applies to Gals."
When everyone had written their sticky notes, they put them on the blackboard. We discussed them and grouped them.
All sticky items had, on my request, been put above the dotted line.

The second phase I appended as the original method, in my humble opinion, lacked action items. I presented two options to the group, and later realized there was a third.
1. Choose one of the properties listed under "That Guy" or under "This Guy", on which you want to work during the next sprint. Note it in your agenda for reference during our next retrospective in 2 weeks.
2. Choose one of the properties listed under "That Guy" or under "This Guy", on which you want to work during the next sprint, and stick it on the board, thus sharing it with the rest of the team.
The first option is very safe. Some participants preferred the first, safe option. The team deliberated about which of the two options, and finally choose the second option.

Afterwards, I realized there was a third option:
3. Choose a teammate, and let him/her indicate what (s)he sees as a weak point which you might like to work on. Note that this remark is intended as a gift, not as a criticism.
If you want to present the third option, you should realize that this may be sensitive. Teammates might feel a remark as criticism. It takes a lot of courage to choose this item. It may easily be (mis)used by team mates to finally throw out irritation which has built up in the team over weeks or months. If you are not confident about your skills as an agile coach to handle such a situation, simply don’t present the third option. The intention of the third option is to give your teammate a gift: give them your insight on what aspect of his behaviour your teammate might grow most or best.






donderdag 11 mei 2017

Agile voting

Of course you want consensus. But building consensus takes time, but sometimes consensus is hard to obtain. Sometimes you don’t have the time to talk on and on, or everybody is bored. Sometimes we need to vote.

Here is a one pager with ways to vote.

Three dots
Execution:
Give every participant 3 dots. These dots may be post-its, or coins, but are usually made with a highlighter
Every participant distributes his/her dots among the options: one for three different options, all three dots for one option, as the voter sees fit.
The option with most dots is chosen (or top 2, or top-3)
You can vary the number of dots as you see fit.

Fist of five
Every participant is asked to raise his/her fist in the air.
Vote leader mentions option and counts from 5 to 0. On 0, every participant raises 1 to 5 fingers simultaneously.
Participants raise 1 to 5 fingers.
Note number of votes and continue with next option.

Roman vote
Everybody votes at the same time in the way on an option in the way that the roman emperors decided on the fate of a defeated gladiator in the arena: thumb up or thumb down. Keep track of the number of thumbs up/down and choose after all options have been voted on.

Planningspoker
List all options.
Hand every participant as many cards from a set of planning poker cards as there are options. Thus, if there are 5 options, each participant gets the cards 0, ½, 1, 2 and 3.
Participants distribute their cards over the options, one card per option.
Item(s) with highest score(s) is(are) elected.

You can find references to the methods described above at the end of this post. Here are two new methods, which I intend to try out in the near future.

Put your money where your mouth is!
Prepare by making small bags with 1 x 50 cent, 2 x 20 cent and 1 x 10 cent
Hand one bag to each participant
Participants distribute their coins over the options, taking turns. Optionally, they may explain to their team mates why they vote as they do.
Option with most money is valued highest.

Race
Prepare a sheet with 4 lanes consisting of up to 12 squares each. Make one marker for every option, mark it with a short one word name.
Hand every participant the cards 0, 1, 2, 3, and 5 from a set of planning poker cards.
Participants take turns to move the markers to the finish by playing one of their cards and moving the marker the number of indicated squares.
Voting ends at the end of the round in which the first item crosses the finish line.
Two or more items may cross the finish in the same round, furthest option wins.

References:
http://www.innolution.com/resources/glossary/dot-voting - dot voting
http://agileforall.com/learning-with-fist-of-five-voting/ - fist of five
https://plans-for-retrospectives.com/en/?id=99 – planning poker voting
http://www.wall-skills.com – roman voting

zaterdag 22 april 2017

The story of a feature

In their book “Fun retrospectives”, Paulo Caroli and Taina Caetano describe an activity “The story of a story”. Last Monday, we used this format to analyze why we had not finished any activity for the feature which we had assigned the highest priority during our planning session.

Different resources on the web distinguish different phases or steps that apply to a good retrospective. I like to group them as:

The activities we performed in our session are:
1. Scrummaster draws the timeline
2. Srummaster explains the technique to be used
3. Scrummaster announces of the scope (what happened during the sprint that influenced not completing these activities)
4. Participants write down post-its with relevant events
5. Participants stick their notes on the relevant place in the timeline
6. Participants explain their notes for the group.
7. Group discusses the notes
8. Group formulates lessons / improvement opportunities / action items

The steps 1-3 belong to the “set the stage” phase. Steps 4 and 5 collect the data, step 6 analyzes the data while step 7 and 8 represent the last two phases. As always, formulating action items was the hardest part of a retrospective.

Example of timeline:

The result was that we had a pretty clear picture of what went well and what went wrong.

Sources:
https://msdn.microsoft.com/en-us/library/jj620912(v=vs.120).aspx
https://plans-for-retrospectives.com/en/?id=106-35-95-73-101