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. In How To Integrate Design in an Agile Backlog, I talked about the specifics of integrating design stories into that development backlog. In this post, I’ll talk about how to maintain a separate Design backlog.

Recall that:

In the past separate design backlogs have been prohibitively difficult to integrate into an agile team’s workflow…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

Previously, we discussed when to use different types of backlogs, categorized various types of stories, and described a general flow for agile design. In this post we won’t rehash that material, but instead will describe some of the practices specific to separate Design and Development backlogs.

A General Flow for separate Design and Development backlogs

So what does this all look like in practice?

Using the Multiproject Workspace

Tracker New offers a Multi-Project Workspace View which is key to unlocking the power of a Design backlog. Your Multi-Project Workspace should include the project Design backlog, as well as the various project development backlogs.

As with an Integrated Backlog, designers’ first responsibility is to ensure that development isn’t blocked by design. Review the development backlog for “blocked by design” stories. For the most part, these should be minor design tasks: cutting assets or interpreting already-made design decisions. Anything larger than that should be cut into a story for the Design Backlog.

Using the Design Backlog

The Design Backlog should first focus on stories which address design independent of platform. Interestingly, this may affect team workflows. On one project, we used to maintain separate files for iOS and Android workflows, e.g. Hamazon-Order-History-iOS.ai and Hamazon-Order-History-android.ai, with stories in the iOS and Android backlogs corresponding to separate files. Once the Design Backlog comes into play, it makes more sense to organize files and make design decisions by user flow, and have separate artboards for the various platforms. Stories might start by focusing on upcoming epics and stories for which design is unknown to figure out the main user mechanics, visual metaphors, and design decisions, and then break out smaller stories to customize for each platform.

Prioritization & Estimation

The biggest danger in a separate Design backlog is dependency tracking. Make liberal use of epics (ubiquitously-named across all backlogs) and linked stories. Make sure to prioritize so that design is a week or two ahead of development. Furthermore, now that the design backlog is clear of development velocity, there’s no reason not to estimate design stories. This is incredibly powerful: not only do we start to have a much more accurate picture of how much design work there is to do and when design work will be done, but estimation forces a cleaner definition of what “done” means for a given design story. This in turn helps to build a practice and culture of sustainable pace in design. But Prioritization and Estimation involve non-trivial amounts work; when do we find time for it?

Design Standups & IPMs

Standup meetings and Iteration Planning Meetings are hallmarks of Agile practice. Now that we’ve got a Design backlog, Design Standup and Design IPM fall out naturally. However, we want keep to the fewest responsible number of meetings. We’ve found that a ~5m design standup with the product team, immediately after team standup, is a good opportunity to review in-flight and upcoming stories in the backlog, get on the same page, and discuss pairing for the day. It often makes sense to do acceptance and estimation as well. Design IPMs can occasionally be scheduled, but often they’re subsumed into other meetings, particularly Pre-IPM. Since Pre-IPM often involves grooming the backlog and looking ahead to future epics, it’s a natural time to review the design backlog and ensure priorities are in sync. Occasionally a separate Design IPM will be called for, but this will probably only happen every 3-5 weeks. With proper management of the Design backlog, this helps scale a healthy, sustainably paced design practice for large projects across multiple platforms.