In How To Manage A Design Backlog, I talked about some of the general ideas behind managing design work on teams where developers use an agile, XP-based backlog—i.e., a Pivotal Tracker-based workflow. In this post, I’ll talk about the specifics of integrating design stories into that development backlog. Recall our goals are that:

design should not block development,

design should know what to work on next,

design can forecast when design decisions will be made,

design might help drive out product vision.

First we’ll discuss when to include design stories in a development backlog, then I’ll classify a few types of stories (and the design work that needs to be done on them), and finally we’ll discuss typical rhythms on a project.

When should I use an Integrated Backlog?

An integrated design backlog is appropriate for small- to medium-sized projects (i.e. teams which can be fed with two or fewer pizzas), focused on a single platform. It can accommodate teams which have designers that code, as well as designers who don’t.

Pros and Cons of an integrated backlog

PRO: simple, easier to see prioritization
CON: no design velocity

In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow, primarily because tracking dependencies across backlogs was too difficult. The game changed when Pivotal Tracker launched its new Mult-Project Workspace View. Now that it’s feasible, a separate Design Backlog is appropriate when you have multiple platforms (e.g. iOS and Android) with design concerns which are independent of platform, or when it’s important to estimate design work without affecting development velocity.

Pros and Cons of a separate design backlog

PRO: more focused backlogs, handles larger projects, measuring design velocity
CON: tracking dependencies between design and development stories becomes difficult

We’ll tackle a separate design backlog in part 3 of this series.

Types of stories

Design needs can manifest themselves in several ways, and are expressed in several different types of story.

Development Stories for Which Design Is Complete

This is the ideal case: development is ready to begin on these stories. A few ways this can happen:

Design decisions communicated by (expensive) high-fidelity mocks accompany a well-formed story.
Design decisions communicated by sketches or comments and supported by a pattern library accompany a well-formed story.

These are development stories in the backlog, with design decisions delivered by attaching mock-ups or comments. It’s helpful to attach a mock or whiteboard photo to the story to 1) make it easy to find the visualization in IPM, and 2) to assert that design decisions have been made. It can be helpful to attach links to mocks and assets in dropbox or pixellapse, but these should be for context only, and not the final deliverable. While it can be helpful to attach documentation to the epic itself, the best practice is to be explicit about where the developers need to look to find design documentation—ideally, within the story itself—and to reduce the number of places they need to look.

Blocked by Design

Regular development stories may have a “▒ blocked by design ▒” label. This label is usually applied in IPM or when the story is in-flight and the developers realize they’re blocked. When applying the label, it’s crucial to write a comment specifying what will un-block the story. Usually this will be “blocked pending asset” or “blocked pending a decision from design about whether it’s ok to combine these two screens into a single form.”

Design-Only Stories

These are stories in which design is (more-or-less) known, but not articulated. Sometimes rough sketches may exist (e.g. whiteboard wireframes or descriptions of design decisions), but designers feel it’s worthwhile to step through the whole user flow. Mocking up known ideas with the actual visual design can help drive out problems and edge cases. Usually this will be done by pasting a Gherkin story into the comments of an Illustrator doc, and then filling in the screens with screenshots of working software, aided by wires or mockups. Occasionally, when interaction design is especially important, the final deliverable may be a click-through prototype.

In the backlog, these stories should be labeled “design-only”, and estimated at zero points. Design stories are a little different than development stories. These stories may include the “As a [USER]…” and “Given…When…Then” Gherkin of the [Well Formed Story][] structure, but the titles lack the Well-Formed “…should…”. Instead, the title describes what needs to be done to make design decisions. Story titles often include the word “flow”: Mock up [FEATURE] flow or Flesh out user flow for [FEATURE]. When the mock-ups have been created, designers will attach them with a comment mentioning any major issues (“we decided on the second approach discussed earlier, and you can see it works both for guests and logged-in users”) and mark the story as done. Because it’s a zero-point story (and not a chore), someone will need to accept it.

Why Zero Points?

We usually estimate these as zero-point stories because we want to ensure there’s a moment to check-in with the product team —acceptance—but we don’t want to have design points skew development velocity. This often changes on projects where the design resource also does development. E.g., on a project where a designer also works on pointed features (usually front-end development), we want to reflect the fact that design work is taking away from development points that would otherwise be earned. In these cases, the designer must do their best to estimate design stories. It’ll usually be a bit of a guess, but hopefully its a small enough number of points to account for work without skewing velocity.

Epics & Stories for Which Design Is Unknown

In some cases, there’s a loose product goal, but the team has not yet agreed on the best way to get there. In these cases, investigate. These stories often entail product and design getting in front of a whiteboard and sketching. The result is often a flow rendered on the whiteboard, with enough context to write stories. Once Investigations are complete, the flow can be added to the epic. Product and Design can review the mocks and generate development stories (this is a great use of a Pre IPM meeting).

Design Acceptance

How do we get to accepted stories? At the beginning of a story, designers will click “start”, do the work, and click “finish” when they’re happy with their design decision. They’ll attach documentation (usually wires or whiteboard photos) and make a brief comment to the effect of “we’ve got a direction we’re happy with, ready to talk to product”, and then click “Delivered”. Product (or the client) will then sit with the designers and review the mocks.

If Product likes the flow, they’ll click “Accept”.

If Product mostly likes the flow, but some minor changes are needed, they’ll click “reject” and indicate what changes are necessary for acceptance. “Rejection” can be a harsh word, but in the context of Agile it’s not bad—it’s just one of our feedback loops.

If Product feels the flow really doesn’t work, that usually means the first attempt was necessary to drive out new questions and problems that were not apparent at first. In this case, click “Accept” on the story, and write a new story called “[OLD STORY NAME] version 2”, and note the new requirements and learnings based on the first story. We do this to reflect the work done on the initial story. Because determining a definition of “done” can be difficult for design, it’s important to mark the progress of work, and to avoid a design story that’s constantly open. Expect to see no more than one or two rejections on a story—either you’re finding design solutions, or learning things which inform your next design decision.

Converting stories from Design to Development

So: a design story may progress from a rough idea through an investigation into a design solution. When this is the first story of it’s epic, it may be useful to convert the design story to a development story. This can be helpful when a lot of the design thinking and history and mock-ups are captured in the comment thread of the story. This is done by clicking “Accept” on the story—we want to honor the work and capture the history—and then unstarting the story, and renaming and re-writing it as a Well-Formed development story, at which point it’s prioritized by Product and estimated at IPM.

A General Flow for Agile Design

So what does this all look like in practice?

When Design Blocks Development

Let’s take the simple case and start from the beginning: a green-field project that’s starting fresh. The project will kick off with an agile inception, which results in a prioritized and estimated backlog. Usually, the stories in this backlog will embody a few larger themes, or epics, and designing those flows is about the right level of fidelity for this round of design. Designers start off by picking up the first epic and sketching userflows on the whiteboard. With a few of those done, the team should have a rough idea of a layout for the app, and developers should have enough context to start building working software. Design is no longer blocking development.

Using Design Stories

Now that development isn’t blocked by design, designers can shift focus to higher-level design concerns. Often, this will mean creating a visual system (which might be is enshrined in a style guide). This places us at the beginning of a Big Design Refactor cycle.

The Product / Design team can then go through the backlog, updating unstarted development stories with the newly-decided-upon visual design, and creating new stories to skin already-built functionality using the new styles. In an ongoing project, this story-wrangling probably happens in a Pre-IPM meeting.

As new epics are created by Product, stories can be written to flesh out new user flows. Usually just focusing on the Happy Path is sufficient, but notable edge cases may also deserve inclusion.

Normal Workflow

Designers start the day by going through the development backlog, looking for “▒ blocked by design ▒” stories. This is analogous to developers checking that the build is green before starting the next story on top of the backlog. If the development backlog is clear of blockers, designers will pull the top story labeled “design-only”. Over time, the project will build up a visual system, add new epics and features which break the system, and refactor the system.

This is one way that proper management of design stories leads to a healthy project at a sustainable pace. In the final installment of this series, we’ll tackle techniques for separating design stories into their own backlog.