Tuesday, November 6, 2012

The Scenario Canvas

After several years of trying, I surrender. I will never get my students to put goals into their user stories ("As a ... I can ... in order to ...").

So, following up on my earlier post about scenario backlogs, and triggered by Roman Pichler's Product Canvas, I'm now experimenting with having my teams plan and report progress to me with Scenario Canvases. A Scenario Canvas is nothing more than a short context scenario plus the exact set of user stories need to support that scenario. No more, no less.

Note that there are no goals in the user stories. The goals, constraints, affordances, and so on, come from the scenario. The scenario establishes a need in a situation. The user stories satisfy that need.

To develop, pick the scenario that is most critical for your business case, e.g., for testing or demoing. You identify the user stories and write them down. Then start with the user story that is the payoff point in the scenario, the point where the user need is met. Typically this is one of the later stories. Hardwire or fake the other stories if necessary. You need to see if the idea really does pay off, or if it needs more. As you go, mark the stories that are done. Some may be already done from a previous scenario.

I expect I will still have plenty to critique in what they send me, e.g.,
  • Scenario bits clearly added just to demo a feature. "Sally wondered how many things she had loaned out, so she opened MyStuff and clicked Loaned count."
  • User stories that align poorly with the scenario need. "Fred was  hungry and stuck downtown. Where could he get something vegan? He open FeedMe, started clicking nearby restaurants and opening their menus."
[Edit: Related is Goodwin's Designing by Scenarios (e.g., slide 55), but I'm not trying to create a design tool. I'm looking for a more focused tool than backlogs  for client/developer communication.]

Thursday, November 1, 2012

The Number One Myth about Teams

Some of the simplest ideas are the hardest to teach because of interference from an equally simple wrong idea. The number one misconception about teams that afflicts managers and team members alike is this:
The purpose of teams is to split up the work.
Follow this and you get silos, low value bus factors, miscommunications, bottlenecks, etc.

Here's the alternative.
The purpose of teams is to gang up on the work.
Follow this and you get pairing, swarming, bonding, low work-in-progress, continuous improvement, etc.