The Business Value Game: v1.0 released

How do you prioritize your backlog?

Business Value Game Persona card

If you want to create a good iteration and release plan, you should make sure that you work on the high value stories. But how do you know which stories have high value? It’s simple: your Onsite Customer will tell you. You do have an Onsite Customer, don’t you?

But how does the Onsite Customer decide? How does your company prioritize stories, epics and projects?

Playing with Business Value

In the XP Game you get story cards with the Business Value number already filled in. That makes it easy to prioritize: just look at Business Value/Cost.

The Business Value Game looks at the problem from the Onsite Customer’s point of view. Vera and I developed this game as a complement to the XP Game, to explain the difficulties facing the Onsite Customer.

We simulate a situation where a group of salespeople sell projects to customers (like Jonathan on the right) and need to decide what the development team will implement. The goal of the game is to make money by releasing features and by keeping customers happy (by releasing features).

Over 6 iterations, we introduce Customer Requests like the one below. Each request generates some income for the company when all the stories in the request have been implemented and released. Delivering a release makes the Customer happy. The players need to define the Business Value of each Request taking into account many factors: potential income, potential customer happiness, constraints, deadlines… Using the estimated Business Value and the estimated Cost (already on the Story cards), the team must decide which stories go into each iteration. Of course, the developers can implement no more than their velocity.

We introduce more and more difficulties and parameters in each iteration: developer output fluctuates, there are dependencies between projects, some Requests are inconsistent, you can invest in process improvement and many more that we can’t reveal now.

Tried out

Tryouts are an essential part of game development. I hosted a tryout at Agile 2008. Last Wednesday Vera and I hosted a tryout at the Belgian XP Users/Agile Belgium group meeting in the offices of Cap Gemini. We received a lot of feedback from the participants at both tryouts. Thank you.

We have so many tips and ideas that we’re thinking of creating two versions of the game: a basic version with 6 iterations in 90 minutes and an extended version with 9 iterations in 120 minutes. As we add more difficulties in each iteration, the 9 iteration game might become very challenging!

Try this at home!

The Business Value Game is licensed as Creative Commons and available online like the XP Game, the Bottleneck Game, the Real Options Space Game and Mirror Mirror on the Wall.


Creative Commons License The Business Value Game by Vera Peeters and Pascal Van Cauwenberghe is licensed under a Creative Commons Attribution-Share Alike 2.0 Belgium License.


Agile 2008 – Final sessions, leaving Toronto

Re-runs and running

The last slot of the conference was filled with re-runs of the most popular sessions. Portia and I were interested in two sessions, but neither presenter turned up at their re-run. While we were waiting for presenters who never showed up, we played the “Mirror, Mirror” game with a few Crispies. A lot of people at the conference were interested in the games Vera, Portia and I designed. Watch out for more games on the Belgian XP users site, the Agile Coach site and the Agile Fairytales site.

Then we realized that “The Agile Playground – Learning Games for the Agile Practitioner” was also re-run. We really wanted to go to this session to learn more about learning game building, but it was scheduled at the same time as Mirror Mirror. We ran to the session, where Don McGreal and Michael McCullough graciously allowed us to join the session midway. We took part in one game and learned some lessons about game development. Don and Michael have a whole set of games at the Tasty Cupcakes site. We exchanged games with the presenters and participants. Like Vera, Portia and I, Don and Michael provide their games free of charge as a way to give something back to the community.

And then Agile 2008 was over.

We talked to a few of the other participants before they left and then went for a walk to the harbourfront to get some sun and fresh air. The evening ended with a fun experiment in simultaneous blogging: Portia and I brainstormed the highlights of our Agile 2008 visit; then we had one minute to write one sentence about each topic in turn. You can see the results here and here.

Goodbye Toronto

Saturday started with a long run along the lakeshore, followed by a walk to Kensington Market, Little Italy and Chinatown with Laurent Bossavit. The beautiful weather was replaced by rain. When we wanted to go on to the harbourfront, a heavy thunderstorm stopped us in our tracks. When the weather let up a bit, we went back to the hotel to leave for the airport. On the way, we joined the stream of people coming out of the Rogers stadium after the Blue Jays‘ defeat at the hands of the Cleveland Indians.

And then we’re on our way home.

Agile 2008 is over.


Agile 2008 – Alan Cooper keynote


Alan Cooper, author of “About Face” and Visual Basic, asks what programming is and isn’t. It isn’t art, science or engineering. It is craft. Programmers are smart, hard-working and eager to please.

The most important part of software are the interstices, the interfaces. Using existing libraries and API’s is alluring, like taking a highway through a swamp. But the library or tool may not be really suited to the task.

We regularly throw away our tools and jump onto new toys. Agile is the new toy. But there’s is no silver bullet. And we have to consider the context to define ‘good’. Agile is unique because it’s the first time developers create a revolution based on people and process, not technique and tools.

The problem with waterfall isn’t only the handoffs. Even worse is the abdication of responsibility and accountability. All roles must remain involved and responsible throughout the four stages of software development:

  • Big ideas
  • Design
  • Engineering
  • Construction

Alan posits that mixing the four stages is the most common source of failure. Agile intends to fix the broken process. Programmers feel surrounded by incompetence. Programmers like Agile as a defence against that incompetence. Agile is a coping tool. Coping with unreasonable clients, incompetent designers, documentation and process excess, foolish managers (who are mostly well-intentioned but use obsolete, industrial-age tools based on command-and-control). Managers have come to expect failure. Success seems random.

Interaction designers and agile programmers are allies. Both of them are craftsmen, work hard and build tangible, testable deliverables. Interaction designers can help programmers to understand business goals and users.

Cooper’s thesis: we can know what users need. Interaction designers are the ones who can discover this.

As expected the slides are gorgeous. They are available at Alan’s Journal.

I’m left wondering a few things:

  • Are Interaction designers the only people who understand customers? Are sessions like the ‘Nine Boxes‘, which help everybody to understand customers, useless?
  • Do developers and interaction designers have to be allies against incompetent managers, or can we work together with competent managers?
  • Will Alan’s 4 step process (Big Ideas, Design, Engineering, Construction) be misunderstood as a sequential lifecycle? Talking about this keynote, I heard some people say that they got the impression that Alan advocated going back to a waterfall-like sequential process?
  • Can we really talk about ‘construction’ in the software domain? If the job is predictable and repeatable we will automate it.
  • There is more to time than being first on the market. Money now is worth more than money later; we can invest our early income in more projects.

SimBlogging: Agile 2008 Toronto Visit

SimBlogging‘ offers a his and hers viewpoint where Pascal and Portia timebox-blog as a pair on the same topics simultaneously

Rough Guide to Toronto

We visit Darwin, one of my heroes, at the Royal Ontario Museum. The Casa Loma fairytale castle on the hill with its stunning library and conservatory put us in the right mood for some agile fairytales. Fred the friendly busdriver took us to the quaint, quiet rivertown of Niagara Falls so that we could buy bells in the Santa shop, where it’s christmas 364 days a year as they’re closed on christmas. The ‘Maid of the Mist’ is a natural thrill-ride: up close and personal with the power of the Niagara Falls you get extremely wet.

Agile 2008

Coming across ‘Bimbo Slides’ is really confusing: the slides look great, like a super-model, but the accompanying text doesn’t fit. Playing with the Leadership Legos, we experienced a few ‘Lego moments’, where you realize that someone else has lived some experience that we can never experience in the same way.

Chilling Out and Staying Cool

After Gino offered us an excellent improvised lunch, Portia thinks that all Belgian boys know how to cook, but she’s only seen 2 out of 5 million, so her conclusions may be premature. Our other Torontonian friend, Allison, told us 400 years of Canadian history in the time it takes to eat a Japanese lunch. We can share our passion for Agile by extending it in ways that were never envisioned (or intended) by the originators of Agile: test-first, paired, iterative and incremental, timeboxed clothes shopping. Consequently, we look sharp as we go out to dinner with Ben, Allison and Gino to discuss scary ideas in English with a funny French accent.

Looking into the Mirror

The “Mirror, Mirror on the wall… Why me?” session contained an agile retelling of Snow White and the Seven Dwarves to help the participants find actions to improve their collaborations and to be more aware of team composition. The Snow White Kanban cards we handed out to everyone we talked to where a hit: the dwarves sparked everybody’s imagination and the cards spread across the conference.

Les Neuf Cases aka The Nine Boxes

We subtitled the French-speaking “Neuf Cases” session in English to create the first and only bilingual session of the conference, so that participants learned to interview and improved their English/French skills; now that’s value for money! The preparation for the session, writing the subtitles in pair with bemused conference participants passing by, was almost as much fun as the session itself.

Value-Driven Presenters

As the conference went on, more and more people came up to us to talk about our games and to tell us how they had extended and used our games. Unfortunately, Vera couldn’t be here to share in the talks about the XP Game and to see how well the first tryout of our new “Business Value Game” went. In between all the talks and fun, there were some sessions that presented techniques that we will apply from now on, like the Conflict Resolution Diagram presented by Christian and Christoph or the 4.5 techniques to assign Business Value and prioritize out backlog presented by Mike.

To relax and reward ourselves for all the “hard work” and to keep the pace sustainable, we built in small treats and celebrations to the hectic touristic and conference schedule.


Agile 2008 – Friday pt. 1


Friday starts off with Corey Ladas’ “Starting a Kanban System for Software Engineering with Value Stream Maps and Theory of Constraints“. The talk contains practical techniques and steps to move to a more Lean, flowing software development system. Typical issues are highlighted. Many of the techniques are familiar to me and I’ve seen almost all of the techniques in use. Teams at different levels of maturity use different techniques. The important thing is to constantly strive to to better, to reduce cycle time. Corey recommends cumulative flow diagrams to quickly highlight problems.

There are some questions about the apparent conflict between reducing waste and increasing flow on the one hand with prioritizing to maximize value delivered. Not every story has the same value, unlike the production environments where flow originated. Aha! A conflict. Can we dissolve it with a Conflict Resolution Diagram?

Read more at Corey Ladas’ blog.