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.