Backlog out. Mind-map in showing user activities and high-level tasks
We haven’t used a conventional list of stories or stack of cards backlog for over a year. We’re lazy. And creating a big backlog that kept on growing with ever more detail and required regular triage was just wasteful. Instead, we’re currently using a mind-map made with Post-It notes, which maps out the different types of users, the activities they’re involved in and the tasks they perform as part of those activities. It’s a spin on Jeff Patton’s idea of a story map but doesn’t require the aircraft hanger. The map is created during a chartering day in collaboration with the client. Here’s an example:
The pink Post-It notes represent the different users. The blue Post-It notes represent the user activities and the yellow Post-It notes represent the high-level user tasks. An example user activity might be ‘play football’. The user tasks are also described at a very high-level. Examples might include ‘take a penalty’, ‘pass the ball’, ‘throw in’, ‘make a save’. (These may be contrived but hopefully you get the idea.) The map is a fluid visualization. As we have more discussions amongst ourselves and with the client and the users, it becomes more representative of the breadth of user interactions with the product rather than capturing depth or feature detail.
Visualizing investment rather than tracking backlog complete
We don’t use a burn-down chart to illustrate how much of the backlog is done. We consider this to be waste because the product is a moving target and the backlog can never done until the product is no longer available. However, we do visualize the investment made in the product to date. Whenever we invest in a high-level user task by building out a story, we place a dot on the task’s Post-It note. We use red dots to represent development work. Sometimes pure design work is performed such as creating paper prototypes modeling various user interactions. In this case a yellow dot is used.
Over time the dots often reveal interesting things about the product, the strategy and its direction. For example, at a previous client, despite mapping out user activities and tasks requiring diverse feature sets the dot groupings showed the tendency of business decision makers to stick to their areas of expertise and prioritize their darlings. The visualization showed deep investment in a few areas making the product functionally quite specific and consequently appealing to a smaller set of users. The lack of broader investment eventually prompted the business to start adding flexibility to the product with other features in order to pursue different users they had identified during chartering. We also surfaced the amount of money invested to go with the dots, plus quantified benefits realized from the investment (this is sometimes difficult to do). This made the prioritization conversations far more meaningful.
Kanban board - Input Queue | WIP | Done
At LSSCUK, Karl Scotland asked me to talk a little about a new layout for our Kanban board that we were experimenting with. The columns of traditional designs started to feel like bars in a prison cell. We wanted something that felt freer with more space to doodle and accumulate interesting and relevant snippets of information relating to work-in-process. Here’s a photo of our latest Kanban board:
On the left-hand side there is an Expedite slot at the top, which is typically for pink cards representing defects. Beneath that is what we call the Sin Bin. It has 2 slots. This allows us to temporarily shift up to 2 cards that are blocked work-in-process to the side. We don’t so this lightly but sometimes there’s only so much we can do to remove obstacles without escalation or magic (which is one reason why we loathe dependencies). Finally, we have a small input queue containing those cards not yet started. The number of cards in the input queue varies but it’s never more than 2 or 3. Often the queue is empty.
Cards that are done are placed on the right-hand side. Done means released if we’re doing continuous deployment or inventory if we’re using a weekly release cadence.
The middle area of the board is the work-in-process. Up to 4 cards can be in process simultaneously (excluding any cards in the Sin Bin). The quadrants provide enough space for the story cards and avatars plus notes, mind-maps, sketches – basically the stuff we’ve discovered about the stories that we want to keep visible. This has proved to be an effective catalyst for discussion leading to exploration of users, their problems, feature solutions, technical options, etc.
When a work-in-process slot becomes available we call a timeout and run a Pomodoro planning game to discuss and write a new story to pull into play. If we know another slot will become available soon we sometimes decide to plan a second card, if there’s time remaining in the Pomodoro session. This second card goes into the input queue until a slot frees up. Huddled around the mind-map with the client we discuss which high-level user task to work on and write a card describing a story related to that task, which can be done in 2 days or less. For a prioritized high-level user task, the approach is to start with a cheap version of the feature, which provides the minimum functionality that allows the user to perform the task. We revisit features over time to add functional depth based on user feedback. The goal is to iterate features to improve the functional effectiveness and flexibility, and enhance the user’s interaction experience. For example, take the high-level task ‘pass the ball’, the first version of this might be a story like ‘pass the ball 10m along the ground to an unobstructed player’ (or, if you’re an England player ‘lob the ball hopefully up the field to the shortest player on the pitch’;). A later story might be ‘cross the ball ahead of a player running down the other touchline’, and so on.
