上QQ阅读APP看书，第一时间看更新

Breaking down epics into good user stories

Always start breaking down epics by simplifying and splitting the outputs. Focus on what the users will see. Decide what is the result of their actions.

As we have seen, all story card templates contain the output. More often than not, the outputs of epics can be split into multiple, still meaningful outputs. If you are using the Model-View-Controller (MVC) software design pattern, don't worry about the model. Worry about your users. Try to create user stories which are simple and will translate gracefully into views. With less technical words, focus on what the users will see as a result of their actions, then create a user story for each of those results, if they solve a problem. At first, don't worry about actions that can result in a problem or nothing. If the user searches for a car in our grocery surplus webshop, that's their problem for now. Later on, we might want to help them, by suggesting something they can actually buy here. Maybe they were looking for carrot cakes, or we might start selling surplus car air fresheners if we identify a need for that. The point here is that it's much easier to have a great and actionable discussion on small and simple user stories than epics.

Have a specific user in mind and create their user story. This will help to break down epics efficiently. If something is useful to them, you keep that part. Otherwise, you rewrite the user story.

It's possible that different personas (more on them in the next chapter; for now, let's just treat them as a group of similar users) would want a different representation of the same data. In our grocery surplus web store, the accountant, the store owner, the warehouse assistant, and the buyer would want a different representation of the same order. It's possible to create a user story for each of those personas, but before researching the users, that's probably a bad choice. It's much easier to pick one user and solve the issues for them. Ideally, that user is you; remember to scratch your own itch.

There are many customer segments you can use to constrain your unruly user stories. For example, focus only on technically proficient users at first, from only one country, one language, probably from only one sector. This might create a narrow user base, maybe less than 1%. Like Wall Street stock traders, you can ignore the 99%.

However, this can be done only for your Minimum Viable Solution. Later during the continuous improvement process, you should start caring for all users or consciously create a product, which is not for everyone. Obviously, the latter is much better because it's impossible to please every possible user.

After you have simplified and split most of the outputs and reduced the target audience to one person, yourself, you might still have some epics. This is when the project calls for a walking skeleton. No, not necromancy, but an atomic implementation of the system, performing a small end-to-end function, linking together the main architectural components.

Alistair Cockburn's walking skeleton definition can help you to reach to create something that can serve as a proof of concept or Minimum Viable Solution. Gojko Adzic and David Evans goes even further with a humorous twist on the walking skeleton, by suggesting to put the skeleton on crutches. This means that you can start with something the user can interact with, and don't worry about linking together the main architectural components. In other words, create a user interface and ship it as soon as possible. Everything else can be placed in future iterations. I love this idea, mostly because this way you can start testing with real users a few weeks or even days after discussing the project for the first time.

Worst case scenario at the walking skeleton step (with or without crutches) will be where we always ended up with no epics, just simple and easy-to-discuss user stories.

Now, we should have good user stories. However, how will you change the world with user stories? The deceptively simple answer is in the next section of this chapter. It's called the 3 Cs process.