Agile 2006: The Planning Game – Chet Hendrickson & Ron Jeffries

Tuesday 09:00-12:30

Abstract

This is a simulation of an agile project, to demonstrate the impact in business value of releasing earlier, the importance of knowing business priorities in order to get the most value and using velocity to estimate release dates.

Summary

This was one of the highlights of the conference for me. Ron and Chet have played this game over and over, and it clearly shows – it’s funny, it works like clockwork, and the messages reveal themselves through the game without needing to be called out. If you haven’t played the Planning Game, and you get a chance to attend one of their sessions, don’t miss it.

The planning game simulates the planning of an agile project. We are told that this project must be completed within six months. There are forty five “story cards”, each numbered, with different numbers in each corner, and our first task is to arrange them in six columns to show management how we will complete the project. Ron and Chet will play the roles of Management, as well as fickle Nature.

We know this is a trick but we can’t figure it out, so we arrange the cards randomly with more at the start and fewer at the end. Along comes Nature and tells us that in our first iteration, we completed four stories. This is disasterous – we had eight planned. The team next to us have completed exactly what they predicted. This is confusing, how are we supposed to know what we can get done?

One of the other teams informs Management that they are unable to complete the project within six months. Management, understandably, is not very happy. “How long do you need?”

“Seven months”, say the team. Hmm. Management decide that one extra month is not too bad, and the team have at least been honest enough to admit that they can’t complete the project on time. “But no longer,” say Management, “or you will be fired. Now plan your next iteration.”

We rearrange the cards for the next iteration, and Nature dictates that this time we once again complete four. We aren’t doing very well here. It’s clear to most people that we can’t complete the project in time. Management are even more impressed with the team who identified this earlier. The rest of us are in the doghouse. How long do we need?

Based on our past performance, we estimate that we need twelve months. With nothing else to go on, we simply use the number of completed stories – 45 / 4 = 11, with one left over. The group average is around nine. The team who asked for seven admit that they actually need longer. Management are not happy.

We break, and try to decode the numbers on the cards, but we can’t. We discuss what Nature was looking at when he came around to tell us what we’d got done. Was he doing some complicated math? We don’t think so. We don’t know. It’s frustrating, but it’s fun, and the lessons are pretty clear. How can you plan projects without knowing how fast you can work?

After the break, Ron and Chet tell us which numbers represents the effort required for the stories, and what our velocity is. Then they give us the chance to replan the project from scratch. Now it’s easy – we can complete in nine months. We argue over which of the stories should go at the beginning and the end.

We eventually put most of the big stories earlier since they represent more effort and more risk, so we should get them out of the way earlier. Then they suggest that each story could have equal value, which would mean we’ve really messed up.

This is another important lesson, and the game drives it home perfectly. We can’t guess the business priorities. If we don’t know them, how can we effectively plan the project?

We finally get this final piece of the puzzle, and they share with us how the value of the stories is represented. Now we can plan properly, and make sure we get the most value for the least effort in the first iteration.

The final exercise is the most powerful. We need to decide when to release.

Ron has created a spreadsheet that graphs the value realized by the business depending on the release date. The logic works like this:

  • Each month, development costs the company x units
  • Each month, the released features generate the company y units
  • Y is the total number of units of value released so far
  • The highest value features are completed in the first iterations

Key points to apply

  • Focus on reducing release time – ultimate goal is to release every sprint to maximize business value.
  • To maximize business value, it’s vital to stack rank stories based on the maximum value realized for the least effort

Agile 2006 – Planning and Tracking on Agile Projects – Mike Cohn

Sunday 14:15 – 15:00

Abstract

The first question on a project is always “when will you be done?” Agile planning takes place on three levels, using relative story size and previous performance (velocity) to plan iterations and releases.

Summary

Agile teams plan at the release, iteration and daily level.

Release planning describes “Here’s where I want to be” – so that we can figure out the best way to get there. Releases usually comprise multiple iterations, because stories are “done” at the end of each iteration – not necessarily cohesive. Estimates at this level are ball park numbers – it should take no longer than 3 minutes to get to the estimate for each story. During release planning, the team explore the solution space and negotiate how they can satisfy the customer’s needs.

At the iteration level, tasks are estimated in “hours I thought a lot about”. There is no negotiation on schedule or budget at this level – long iterations with varied lengths don’t work. At the end of the iteration, get feedback of what’s done and left to do.

At the daily level, the daily stand up meeting is used to plan the next day’s work and synchronize the team. This should not become a status meeting.

Humans generally are bad at estimating the duration of a task, but relative sizes are more straightforward. Some teams use t-shirt sizes to estimate stories, but it is difficult to agree on the relativity – is a large story twice the size of a small one, or three times? Story points, which are the most commonly used now, make this straightforward.

A common mistake is to consider the skill of an estimator important – it isn’t. Regardless of time, people can agree on the size of a piece of work.

To estimate velocity, use a range. When considering the long term average, look back 4-5 months and no longer, as the team’s situation will have changed too much if you go back any further. Use the velocity to look at the release plan and estimate where we’ll finish at the slowest velocity and expected velocity. These estimates can be used to reprioritize the stories.

Burndown charts show progress. Teams generally work best when they have slightly aggressive, but not unrealistic, schedules – which is why the end of the burndown chart is usually steeper. Burndown charts raise questions – they don’t answer them, but they identify areas for further discussion and commentary.

The powerpoint contains diagrams, further explanations, and photos of example taskboards.

Key points to put into practice:

  • Use velocity to estimate the relative likelihood of stories being completed in a release, and use this to drive reprioritization.
  • Use burndown charts to identify areas for discussion, where further explanation is needed.
  • Track velocity only about 4-5 months back – changes in the team’s situation can cause velocity to change over time.