How To Maintain Separate Design and Development Backlogs

I just blogged about How To Maintain Separate Design and Development Backlogs over at the Pivotal Labs blog.

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.

Check it out, and let me know what you think in the comments!

UPDATE: Go read Part 1 How to Manage a Design Backlog and Part 2, How to Integrate Design in an Agile Backlog.

Advertisement

How To Integrate Design in an Agile Backlog

I just blogged about the How To Integrate Design in an Agile Backlog over at the Pivotal Labs blog.

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.

Check it out, and let me know what you think in the comments!

UPDATE: Go read Part 1, How to Manage a Design Backlog and Part 3, How to Maintain Separate Design Design and Development Backlogs.

How To Manage A Design Backlog

I just blogged about the How To Manage A Design Backlog over at the Pivotal Labs blog.

Every project is different, but Agile and XP have taught developers a stable and robust set of tools for managing (development) work. What about managing design work? (With apologies to Tolstoy :)

[DEVELOPMENT BACKLOGS] ARE ALL HAPPY; EVERY [DESIGN BACKLOG] IS UNHAPPY IN ITS OWN WAY.

A designer colleague asks:

I’d love some insight into how other people use [Pivotal Tracker] / attach mocks and keep things updated as stories split and get added. I’d love to learn how to spend more time working on design rather than managing it.

There are many approaches to managing design and integrating design work with development work…

Check it out, and let me know what you think in the comments!

UPDATE: Go read Part 2, How to Integrate Design in an Agile Backlog, and Part 3, How to Maintain Separate Design Design and Development Backlogs.

 

Subjective Design & Objective Design

I just blogged about the Subjective Design & Objective Design over at the Pivotal Labs blog.

“DESIGN” IS A MESSY WORD
When people ask what I do and I reply “I’m a designer”, their first reaction is often to point at my chest: “Oh! Did you design that shirt?”

“Not that kind of designer,” I reply.

Next they’ll point somewhere around the room. “Oh”, they’ll say “did you hang that wallpaper?”

“Not that kind of designer”, again. Rather than let this game play on, this is usually the time to describe web design, interaction design, product design, visual design, UX design, UI design, etc. The content is tailored to the design-literacy of the interlocutor, but the story is the same. Modern “design” in the context of building products is a mix of many different design disciplines (and: naming things is hard.)

Check it out, and let me know what you think in the comments!

Sustainable Pace, Agile, and the Big Design Refactor

Kate Rutter drew amazing sketch notes for my talk on Sustainable Pace, Agile, and the Big Design Refactor (video, deck) from the Balanced Team 2013 conference. Thanks Kate!

Minimum Viable Deliverable

I just blogged about the Minimum Viable Deliverable over at the Pivotal Labs blog.

As a business, design is built around deliverables: clients pay for wireframes, mockups, prototypes. As a practice, these deliverables are a means to a single end: communicating design decisions. The Agile Manifesto prefers “Working software over comprehensive documentation”, so why are designers spending time on artifacts the user will never see? Agile seeks to minimize waste, so taken to its logical extreme, all documentation is waste. That doesn’t mean documentation can (or should) be done away with entirely; it’s necessary for teams to function (particularly at scale). But it does suggest that minimizing documentation is a Good Thing, and that designers ought to be seeking to communicate design decisions with the least amount of work possible. Welcome to the Minimum Viable (Design) Deliverable.

Check it out, and let me know what you think in the comments!

How to Organize Layers in Adobe Illustrator

I just blogged about the Organizing Layers in Adobe Illustrator over at the Pivotal Labs blog.

Over the years, I’ve evolved a standard structure for organizing layers in Illustrator. Whenever I fire up a new Illustrator doc, one of the first things I do is create and name the following four top-level layers:

Check it out, and let me know what you think in the comments!

How to Use Lean Hypotheses to Define a Minimum Viable Product

I just blogged about the How To Use Lean Hypotheses to Define a Minimum Viable Product over at the Pivotal Labs blog.

Many people new to building apps fall in love the moment they learn about the idea of a Minimum Viable Product. “It’s minimal! So there’s less risk. And it’s viable! So it’ll prove something!”. Unfortunately, it’s easy for the line of “minimum” or “viable” to slip. How can a team stay focused?

Lean Hypothesis are an effective way to help the team connect the problem they’re trying to solve to the product they’re building…

Check it out, and let me know what you think in the comments!

Introducing Hamazon.com (for all your example-app needs)

I just blogged about Introducing Hamazon.com (for all your example-app needs) over at the Pivotal Labs blog.

Hamazon, your Fine Purveyors of Pork Products since 2010, is the default example I use so as to have a consistent example of a software application whenever I tell stories. In the spirit of Convention Over Configuration, it’s helpful to have a go-to narrative rather than inventing a new example for every story. Because Hamazon bears striking similarities to a certain e-commerce site, most people grok it quickly…

Check it out, and let me know what you think in the comments!

“Markdown By Default” is a great convention for notetaking

I just blogged about “Markdown By Default” is a great convention for notetaking over at the Pivotal Labs blog.

Adopting the convention of writing notes in Markdown has been hugely helpful for me. It’s an easy-to-use, easy-to-read, easy-to-learn, format for something I do every day, and a great example of convention over configuration. It helps to capture notes and events in high fidelity, at low cost. I can listen to a conversation and write almost automatically without having to think about how to structure my notes. I don’t have to decode my notes for other readers. It Just Works.

Check it out, and let me know what you think in the comments!