December 10, 2008


Louis did a far better job of blogging about the session I facilitated at KaizenConf than perhaps I ever could. He has a three-post series that describes and combines ideas from the session on Activity Modeling convened by Michael Long.

Coming out of the conference, I have way more blog entries that I want to write than I have time to write them. I'm going to put out some teaser titles here to give you an idea of where I want to head over the next month or so. If you're particularly interested in something, let me know, and I'll focus on that one first. Otherwise, I plan on writing in the order listed below.

Single Piece Flow and Kanban are not the same thing

As lean software development gains popularity, many people are blogging about and starting to apply it, with largely great results. But I think that some of the semantics are getting confused, and to a poor end. I'll clarify my concern, and discuss how to move forward with a clearer understanding of Kanban and Flow.

Driving toward the goal: applying standard work to software development

Here, I'll discuss the design of the workshop and my expectations. I'll talk a little bit about some of the choices I made the week before and then while at the conference to adapt to some changing circumstances and personal goals. I'll discuss what actually happened in spite of that, and I'll talk a bit about what I would do differently next time.

Outcome Driven Development

AKA Goal-Driven AKA "On Purpose" Development. How we can use goal statements and intermediate objective maps to increase profitability, eliminate gold-plating, and have more fun writing software.

Inflicting Change and Agile Adoption

With Agile crossing the chasm, many organizations are mandating adoption. This can lead to broad-scale cargo-culting and mis-application of practice. There were several reports of teams having high turnover numbers when adopting agile. What do we need to do to stop that trend?

Start where you are, not where you think you ought to be.

Kanban is receiving a lot of attention lately, and for good reason. Kanban provides a powerful tool to optimize toward flow and recognize which parts of your process require the most attention. One of the best things about Kanban is that you don't have to adopt new practices apart from work-in-progress limits and pull. These two are relatively simple conceptually, but difficult when executed. It is actually dangerous to adopt Kanban and change up the process at the same time.

To why, a who what (where, when, and how much) and activity modeling

Elaboration on a previous post about user stories. Why I think user stories as currently written according to popular practice are actually more hurtful than good, and what I suggest you do instead.

Why stories are better than use cases

[Some] stories are better than use cases, because they focus on the goals of the user rather than the use of the system. By focusing on the goals, we give focus to the use of the system so that we can eliminate gold plating.

Why stories are worse than use cases

Use cases provide more scaffolding and prescription. This can make them easier for novices to adopt and be successful.

SAFE Scenarios

People have goals. We build technology to enable them to attain their goals more effectively.

SAFE and Minimum Marketable Features

I often wonder what makes something marketable. Why do people like to buy iPhones? Why do some iPhone apps get purchased more than others? Here, I'll discuss the S.A.F.E. scenario idea from a naive marketing point of view.

Agile and Sub-optimization

Once upon a time, there was a team. The team was constantly under pressure to deliver, and they were constantly behind schedule and over cost. They adopted agile, and got much better at delivery. So much so that management cut their team in half in a sad bit of cost accounting.

Creating a Structured Environment for Learning using Kanban

This is essentially a regurgitation of the standard work workshop from the point of view of software development/continual improvement.

Improving Day

One of the outcomes of the KaizenConf was to create a day of improving (I'm biased toward "Improving" :). Come up with simple improvement experiments, conduct them, blog, twitter, whatever the results.

July 31, 2008

Refactoring User Stories

The current vogue means of specifying a story as popularized by Connextrix, Mike Cohn, Dan North is the form:

As a <WHO>, I can <WHAT> so that I can <WHY>.

This form has a number of benefits. It captures what the benefit of the story is, who benefits from it, and it does so in a simple, single sentence structure. It is written in the first person, which has some positive psychological effects on the reader of the card, in that it places the reader in the frame of mind of the WHO in question. All told, a strong format.


I often find in practice that the format is actually written more like


The GOAL of the story, the WHY, is reverse-engineered from the WHAT after the fact. This typically has one of two net effects. In the first case, the cards are accepted at face value, introducing the potential for both risk and waste into the system. In the second case, the development team is forced into a "root cause" search via "5 Whys" or some similar technique to validate that a smelly story in fact does contribute some value to the users who are subjected to it. This creates a source of tension between the development team and the customer, because the team is forced to question the customer. What we instead need to do is to place the goal before the feature and ensure that the sentence makes sense in that order. This has a remarkable effect on the quality of the stories.

Now, I struggle with the particular formulation. I have some simple goals in mind. I would like as much as possible to keep the good aspects of the earlier format, especially the psychological effects of using the first person.

As a <WHO>, I <WHY> By <WHAT>.

I am also fond of the following formulation, although it is not written in the first person.

To <WHY>, A <WHO> <WHAT>.

If you currently use the more popular story format, I would love for you to take a story or two, reform them in the two latter formulations, and post them as comments. I'll post some concrete examples as a follow-on to this post when it is not so late.