Elephant Carpaccio (on user stories)

In our weekly book club, we performed an exercise by Alistair Cockburn called Elephant Carpaccio. The goal was to improve our ability to split stories along smaller story boundaries instead of in more primitive ways, and to learn to develop in an extremely iterative way - in iterations of 10 minutes.

The theory

The theoretical part was covered by this article by J.B. Rainsberger. The ways in which you can split a big story go from the most intuitive one to the last, really focused on transforming a story into a group of smaller ones instead of in a group of task:

• along process lines: first development, then tech review and QA.
• along architectural lines: first the user interface, then service objects and then database tables.
• along procedural lines: first payments completion, then reports and renewals of subscriptions.
• along story lines: each sub-story has the INVEST properties.

I won't go into the nice properties that smaller stories have over more naive approaches, just describing the INVEST acronym. Stories must be:

• Independent from each other so that they can be prioritized easily.
• Negotiable so that scope can be defined together with the customer.
• Valuable so that each one is considered useful by the customer.
• Estimatable so that prioritization can take into account costs and cycle times.
• Small so that they don't stay in development forever, impacting on iterativity.
• Testable so that we know when we're finished.

Practice

We choose the Game of Life as a well-known problem to divide into stories. However, we just defined one story at a time before each iteration instead of definint them all before starting, preferring feedback of the development phase over a full plan.

1st story

The first story was: develop an UI of the Game of Life which shows a 3x3 grid over the infinite plan, with a bar composed of 3 blocks rotating and displaying itself vertically and horizontally. Just for 10 time units.

You can see this story is very limited in scope, since even and odd frames of the animation are all identical. The only way to implement this in 10 minutes was to stub away all the rules of the Game of Life, and show alternatively two fixed frames:

for (i = 1; i <= 10; i++) {
  if (i % 2) {
  // 000
  // XXX
  // 000
  } else {
  // 0X0
  // 0X0
  // 0X0
  }
}

So far so good: every pair could make a demo at the end of this first iteration.

What we learned: severely limiting scope can provide feedback from the customer over an UI even after 10 minutes.

2nd iteration

Here comes the second story: provide a NxN view over the fixed bar rotating instead of a 3x3 field.

The technical debt exploded, and no pair was capable of finishing the iteration with a working demo.

What we learned: the client will always be happy with functionality. It's your responsibility to declare an iteration successfully finished (the 1st one) when you are sure you didn't introduce technical debt. Otherwise cost of change is always going to raise.

3rd iteration and following ones

Given the failure of the 3rd iteration, we came back to the first iteration to develop a stable foundation instead of accruing technical debt. It was, however, impossible for us to develop a 3x3 grid in 10 minutes without any kind of technical debt; so we had to reduce the scope further.

The other starting points reduced the number of iterations (just 1 instead of 10) to only show the user interface, or the initial configuration of the game (a single alive cell instead of a stable mutating configuration like the bar of 3 cells. An intermediate choice can be to choose a stable, but not mutating configuration like the block:

0000
0XX0
0XX0
0000

which always remains identical to itself in any number of iterations. It is debatable whether these reductions in scope make the initial story not valuable, and this is where having a real customer or Product Owner would come in handy as with a simulated one it's a matter of opinions.

What we learned: it's always possible to cut more, but respecting the INVEST constraints is not simple.

Conclusions

We held a very quick retrospective on the exercise at the end of the 4 Pomodoros, finding out that:

• the Game of Life was considered a good problem for the exercise by someone, and not good by someone else. There are many other problems (even simpler like FizzBuzz) available for you to choose, but I usually like the Game of Life as a reference frame.
• I was thinking about involving a non-technical colleague as customer, but it can make the exercise longer to perform and difficult to rein in on the aspects we consider important. Maybe talking with Product Owners is a separate exercise from this one.
• The feedback of the code is invaluable, as what seemed simple to implement exploded after 10 minutes due to technical debt or even in a single iteration for its unfeasibility. Optimism is not always warranted as reality ensues...