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.]

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.

Riesbeck's Rules for Flinching

Agile thinking is fine, but agile feeling is even better. If you want to do things right, it helps to react negatively and viscerally to doing them wrong. These days, I can't help flinching as soon as I hear someone say that they

• are working on anything the client / end user can't use
• are waiting for someone else to do something
• are making something complete
• are too busy to write tests
• haven't shown the client anything new this week

Wait a minute! Writing tests is writing something end users can't use. You're being inconsistent!

Only if you think the goal is to never flinch. Software development is a tightrope walk over Niagara Falls.   You have to expect to flinch a lot. The goal is to flinch less often and less hard.

Or, alternatively, turn these rules into a drinking game. Take a drink every time you hear one of the above things. The worse things get, the less you'll care.

Me and my liver will stick with flinching.

The One-Button App

Since my friend and colleague Todd Warren has made a brief reference to it, I figured I should try to explain one-button apps, and why I push [sic] them.

With a one-button app, you achieve your primary goal with just one button push. No click click click check select check click submit. Just "do it." Todd's favorite personal example is the Flashlight app for the iPhone.  Press a button and the light comes on. It's one of the few apps he liked enough to buy the premium version.

Twitter is a one-button app. Type and send.

Angry Birds is a one-button app. Stretch and let fly.

There's a reason Amazon patented and fights to protect 1-click buying.

If your product isn't a one-button app, how can you expect anyone to really get it in a 5 minute pitch? If your first testable release isn't a one-button app, how can you tell what your users really feel about your core value proposition, and not other issues?

Most initial student ideas I see for smartphone apps fail to find the one-button essence of their idea. Students design apps that are too general. General is often the enemy of simple.

Take the example of reserving courts (basketball, tennis, squash, etc) on a college campus. The general solution is a classic calendar-based event scheduler, where first you have to select the type of court, to get the calendar of reserved times, then do the usual time selection rigamarole -- and you haven't even contacted the people you want to play with yet.

To get a one-button app, first pick a common use case, like arranging pickup games. Those are always the same people on the same court type. When you start the app, all you see are buttons for today's free times for that type of court. Press one of those buttons reserves the court and notifies the people you play with. They get a "can you play at ..." message with buttons to say "OK" or "Can't make it." If too few OK's are registered within the next hour, you get a message and buttons to "Cancel" or "Keep."

That's it. Just one button push to do what you normally want to do. Only on the first use, do you have to pick a court type, and, when you pick a free time, say who to notify. These choices are remembered for future use. They're easily changed, along with many other options, via a preferences panel.

But the core value of the app is in that one button push.

Scenario Backlogs

Here's a problem I've seen a lot in my conjoined MPD 405 / EECS 394 software development course: poorly motivated iteration backlogs.

  Me: Why did you tell your team to build that this week?
  Them: It was the highest priority item.
  Me: Why?
  Them: It's a must-have for our MVP.

That's really no way to run a railroad. It definitely isn't planning like there's no tomorrow, because you could easily end up with 3 top priority items for 3 different user types, and nothing to deliver for anyone. Importance by itself isn't enough to determine coherence.

What I teach now is to create scenario backlogs. A scenario backlog is the set of user stories needed to support a complete user scenario. Until you have complete scenarios working, you have no demo, and not much you can use to get validated learning. An example I used in my fall class on mobile app development was an "exercise buddy" that would let a user create sets of exercise routines. The user could then "run" a workout, and the app would call out the steps for the user to do. There are a number of user scenarios needed for the MVP:

• End user starts the app and selects a workout. App calls out the steps for each subroutine in a workout set, switching automatically, and logging the workout in a diary at the end.
• End user reviews and modifies the workout, including getting new routines from the server.
• Trainers partnered with the app developers create routines on the server for end users to download.

(Don't push me on this. The only exercise I do is hyperventilating if you count that as aerobics.)

If you look at must-haves, there are plenty, from the calling out of workout steps to the server-side entry of  expert-designed routines. If you just pick must-haves for an iteration, you don't get much guidance.

Instead, prioritize scenarios. Which scenario will determine whether this is a viable product? I think the answer is clearly the first scenario. If no one wants to use their phone to direct their workout, don't even bother with the rest.

Make a scenario backlog consisting of all the stories needed to make the first scenario work for real. We don't need to support editing workouts, or entering routines on the server. We make a canned workout routine and get all the text to speech and timing and so on working.

Work on just those stories, over one or more iterations, simplifying when possible. When done, you can start doing some real user testing and find out what else people want, like maybe responding to "pause" or "repeat" verbal commands, or music.

While validated learning is happening, work on the next most important scenario.

The nice thing about a scenario backlog is that a scenario provides coherent comprehensible contexts for writing acceptance tests and for deciding what the simplest thing is that could possibly work.