Go to Agile 2009

Go visit the Agile 2009 blog to get the latest on this year's conference from my work colleagues.

Planning Poker... A Better Way to Estimate as a Group

I've mentioned in some previous post that I would explain the basics behind planning poker and how it could be used to make your team sprint planning session more fun and more accurate. This is a technique normally used for estimating the relative complexity of the items in a product backlog but it can also be applied to estimate the time for tasks in a sprint backlog. So, here it is.

Planning poker is based on the collective intelligence principal were it is said that the collective knowledge of a group will outweigh that of any one individual in that group. A detailed breakdown of this can be found in a book called the Wisdom of Crowds by James Surowiecki but I will try to sum up this idea as best as I can and explain how it applies to collective estimation.

A scrum team is generally formed of individuals having different expertise. Some people are good at testing; others at designing systems and writing code and some have knowledge relating to user interfaces. As a scrum team, each member should know enough about each feature (or user story) to implement them. This is what makes the scrum team work well as a group. Pooling this collective knowledge of the features, each member is able to estimate to the best of his knowledge and expertise the amount of time a feature can take. It is by combining these estimates that a consensus can amount to a very accurate estimation.

What planning poker brings to the table is a fun and an enticing way to get this collective knowledge out of each team member.

How to Play

1. You will need a deck of planning poker cards (index cards or Post-Its can be used as substitutes)
2. Each members of the team get a hand of cards
3. Each hand is composed, for example, of cards with the following values ?, 0, 1/2, 1, 2, 3, 4, 5, 8, 13, 20, 50, 100
4. Each number represents a unit of time such as real hours, man-hours, half-days, etc... You should define this for your group
   
5. When estimating for a feature, each member picks a card and places it face down on the table
6. When everyone picked a card, the cards are turned
7. If the estimates vary a lot, the team discusses the reason why higher/lower values were drawn within a preset time limit and the hand is replayed
8. This is repeated until the team converges to a similar estimate

Explanations

The values of the cards can vary from deck to deck but the important aspect of the series to observe is that it is non-linear. The reason for this is that bigger features are harder to estimate so; the bigger numbers represent ruff estimates. The extreme values are explained here:

• ? should not happen often but when it does, it is an indicator that the information about the feature is not know well enough by the person to estimate. This means that further explanations to the team might be required
• 0 means that the feature is already done
• 50-100 might be an indicator that a feature is too big and that in order to obtain a more accurate estimate, it should be broken down

When the estimation round is played it is essential that each team member finish picking his card before all the cards are revealed. This is to eliminate the estimation by a single subject matter expert that can potentially influence the estimate of others.

I hope I have made myself clear enough for you to better understand the usefulness of planning poker and if you are still confused, I suggest you look it up on Google for there are many explanations and perhaps variations of this out there.

Still not convinced? I suggest you try it at least once.

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:

http://mitchlacey.com/index.php/Resources.html

Back from Toronto

I haven't updated this blog since about Wednesday last week but I plan to post some more material this week. I got back from Toronto an hour late because of some guy who didn't deem it necessary to hurry up from his connecting flight from St-John's New Brunswick. It took him 30 minutes to get from one gate to another; his luggage even beat him to the plane. The pilot wasn't too happy about this and totally ripped on the guy on the airplane's PA system when we pulled back from the gate and made our way to the tarmac.

As I re-read my notes and draft up some more material to post, here is a non exhaustive list of various quotes I picked up during the conference... enjoy and keep reading:

“The best metric of a code review is the number of W.T.F. per minutes” – Uncle Bob

“Agile means good engineering practices” – Mary Poppendieck

“A good scrum master is seen but never heard” – Ken Pugh

“It's not an iteration if you only do it once” – Jeff Patton

“Any tool can be misused” – Henrik Kniberg

“I don’t know what I want to I know how to get it” – Sex Pistols

“The only way to go fast, is to go well” – Can't remember who said that

Impresions of the Conference so Far...

I must say that I am quite satisfied with the Agile 2008 conference so far. I was lucky enough to have picked some interesting topics with very good presenters. I also had the mischance of selecting topics which had a seemingly good title and abstract description but I ended up ditching the presentation about 20 minutes in because I didn't feel the content would be very relevant to my personal goals of being at this conference.

I would like congratulate the organizers for the smoothness of how things are going however I have the following two "complaints/suggestions" I would like to make for next year's conference.

1. There are way too many good topics to choose from. Multiple topics provide a very broad coverage of many subjects however, being only two delegates from my organization, I am sure we have missed out on some VERY interesting topics and presenters altogether.
2. In relation to point 1 is the missing presentation material from the conference CD. I understand that having all the presenters submit their material beforehand can come with its load of logistical problems but I find that many good talks which I would've liked to attend are missing from the CD.

I'm the organizers will provide us with some way to access the missing presentations because I would like to read up on some of the presentations I couldn't attend.

Tomorrow is day 4 of the conference and will be by far the busiest day with four sessions and the banquet keynote speech. I'll be posting some more info tomorrow morning because agile conference reporter is exhausted.