Agile 2009 report: Thursday

Feature Injection A Gentle Introduction by Kent McDonald with sporadic contributions by Chris Matts

Most of today’s sessions are about business analysis. This Feature Injection approach looks a lot like what I do, but explained at a very high level. Essentially it boils down to:

  • Identify Value: make sure you have a business value model which defines the type of value projects seek: increase revenue, decrease cost, protect revenue, reduce risk, increase information…
  • Identify Capabilities: what is the minimum set of capabilities we need to realise the value(s)?
  • Get lots of examples: understand what exactly happens in different circumstances

Or stated differently:

TO realise < identified value> AS A <actor> I NEED <identified capbility>. GIVEN <example situation>, WHEN <example action> THEN <example outcome>.

Now we just need a way to find those pesky actors who deliver the value.

Beyond User Stories: Identifying Missing Links in Your Product Backlog by Ellen Gottesdiener

This session focused on the requirements that don’t neatly fit into the User Story mold: non-functional qualities, implementation and design constraints, cross-cutting concerns. How do we represent these?

  • Write specific User Stories. E.g. AS A CTO I NEED the solution to be deployed into environment X SO THAT our support costs remain constant. The advantage is that the rationale is clear. The disadvantage: this story is never done.
  • Add extra constraints to the User Story. E.g. AS AN accountant I NEED report X in 5 seconds SO THAT….. The advantage is that the information is directly associated with the story and has user meaning. The disadvantage is that there are usually several criteria, so the User Story might get very complicated.
  • Add constraints to the “iteration definition of done” or “release definition of done”. E.g. all modified or new functionalities must be documented in the User Manual before the iteration ends. Advantage: useful for recurring needs. Disadvantage: may lead to implementing and testing these requirements late, so that nothing is really DONE until the end of the iteration or release, batching up work at the end.
  • Add acceptance criteria. E.g. GIVEN a session at the conference WHEN I select the details THEN the full session description is displayed within 3 seconds on any web browsing device. Advantage: concrete, leads to lots of questions as we explore scenarios, leads to automated acceptance tests. Disadvantage: where do you put the tests: story, module, application, global?
  • Other techniques like planguage or simplified text descriptions of constraints.

One extra tip I would add: define service levels.

Service levels

For many non-functional criteria we can define a limited set of “service levels”. For example we could have three security levels:

  • Top secret: nobody can see it, until it’s published in the newspaper
  • Private: only the person concerned + HR can access the information
  • Public: anybody can access the information

Or we could do the same for response levels:

  • Blistering: answers within one second
  • Snappy: answers within 3 seconds 98% of the time
  • Relaxing: answers within the time to take a lunch break

Now, instead of discussing (haggling) over details of non-functional requirements (“is 1.5 seconds fast enough? No? 1.4 seconds?…”) we put each story into a service level “bin”. Most User Stories can be classified quickly. We can annotate the User Story with the appropriate set of Service levels in each of the dimensions. We can subject the User Story to standardised acceptance tests that verify if the implementation does indeed comply with the rules of the service level.

For those few stories where the standard service levels aren’t a good fit, we can create customised criteria and tests. And of course, we’ll review and update the service levels when we see that the classification doesn’t fit any more. As long as we keep it simple, with few levels, we can communicate and work efficiently.

More games

This afternoon I go to see two more games:


Agile 2009 report: Wednesday

Good morning ChicagoGames, games games

toc_consultantWe innovated with The Bottleneck Game to be able to accomodate more participants: Portia and I ran two parallel simulations with two groups. Between each round, everybody got back together to share lessons and improvements. As it was only the second time we’d run the game this way, we were a bit nervous. But the game went very smoothly. By the end our smiling participants were uncertified Theory of Constraints consultants. From now on, they’ll see bottlenecks everywhere.

One of the participants who played the role of consultant when so far to as to plot the game on his portable whiteboard so that we knew our cycle time and could see where there were hiccups in the process.

The Business Value Game was too crowded and noisy.  We wanted to limit the number of players because we know that too large teams have difficulty to reach consensus. Unfortunately, the room wasn’t large enough to let extra participants sit on the sides as observer.

Business Value PlayersTelling Your Stories: Why Stories are important for your team by Johanna Hunt and Rachel Davies

In this interactive workshop we got to tell stories with the help of different sets of cards. A simple, fairytale-like set of cards led us to tell a meandering story about foxes, witches, queens and treasure. A more complex set of cards with multiple meanings led to a nightmare-like, surreal story with incoherent jumps.

Telling stories allows us to add meaning and emotion to the information we’re giving. The cards add a tactile and visual element to touch on more of our learning modes, not just hearing or reading. These techniques are useful for retrospectives, training and coaching.

‘Flirting’ With Your Customers by Jenni Dow and Ole Jepsen

Another interactive session, where Jenni and Ole used a flirting metaphor to help us to connect and communicate better with our co-workers. The session was built around and eight step model:

  • Radar: first you have to be aware of yourself and your environment
  • Target: you have to choose who you need to connect to
  • Move in: show interest in the other’s perspective and connect
  • Back of a little: give the other person the room, the option, to connect with your or not
  • Open up: share something personal
  • Dance: have fun together
  • Get real: overcome problems together
  • Enjoy!

The flirting metaphor was unexpected and could have been awkward, but Jenni and Ole’s humour and the openness of the participants made it a fun session.


There are a lot more interesting sessions on Thursday. Looking at the program the theme for the day is likely to be “Business Analysis” because I think it’s essential and we’re still not getting it right. Unfortunately, that means I’ll have to miss Tsutomo Yasui’s Kanban Game.

More about today’s sessions later.