I’ve seen a lot of good arguments for working off the same backlog and having everything visualized there, if you are a cross functional team.

If you think there’s a linear flow through the whole team, you might want to add design stages on the left side of a board, e.g. backlog → research → design → validation → ready for development → development → testing → staging → production.

In this kind of system, individual items that do not need design can of course skip stages and go directly to the (prioritized) ready for development column.

A key benefit of a shared backlog and process is that it’s easy to see what’s going on, identify bottlenecks, work piling up etc. Lastly, something to avoid is doing a ton of design upfront, filling the ready for development with items that *might* be built months from now.

Amazing, thank you for these recommendations @boren! Curious to hear why you’d recommend against doing design work ahead of time?

I’m not entirely against doing design ahead of time, but I’d be mindful about the amount of work. The world around us changes all the time, and this means that the priorities on products also shift.

Releasing products — and design — in small continuous iterations reduces the risk of design ”going stale” or being outdated. As designers we can test things ahead of time with prototypes or wireframes, but I the true validation happens in production environment with real users.

@mattstrom has a good piece of writing that digs a bit deeper from a few years ago here: matthewstrom.com/writing/just-i…

Ohh, fantastic, thank you! I’ll give this a read 🤓

Mine live alongside the rest of the teams, just with different labels, but it’s useful because they can get tagged as blocking etc. the design tickets, however, don’t get tracked in terms of team performance

Ah very nice. Appreciate you sharing! Could you share more about the tracking part? And once you finish a design ticket, do you re-assign to anyone? A developer or PM? I’m struggling with what counts as “done” for a design ticket, as “done” usually means shipped.

FWIW we use a tool called linear which allows labelling, Kanban style columns, sub tickets and related blocking tickets. Everyone’s tickets live together, and design tickets are just for design, but have related tickets for dev that are ‘blocked’ by completing design tickets.

I usually create an ‘epic’ ticket that lives in the backlog that’s purely a parent of all design tickets, so you can see progress. Once initial design ticket is done, dev can start. A lot of design finesse happens in browser so I work with devs iteratively.

We were using scrum but experimenting with ShapeUp now so try and scope things end to end eg basecamp.com/shapeup/3.3-ch… and ‘done’ means deployed in prod.

Linear gives a ‘burn up’ chart so you can see velocity related to time (you have to be hot on estimating relative sizes of tickets) + keeping tickets as atomic as possible means you can zoom out and see how many in todo for both dev/design - great at getting a progress gut check.

Keeping tickets focused on a single thing helps comments stay clear. Finally we have sep tickets for release/comms/help docs etc so ‘released’ means everything has been completed. Can be stressful but I’m loving the process at the moment!

Super helpful, thanks so much Al!

I like having everything together so devs can see what I’m doing (and what’s potentially coming up for them)

Awesome, when you finish your design work, is there a separate or related ticket for developing your design? Or do you re-assign to a dev or PM?

Kinda depends on what comes out of the discovery/exploration efforts. It might turn into multiple dev projects. If it’s straightforward I’ll just reassign (though we’re not working true scrum fwiw)

Good to know, thank you for sharing. You mentioned discovery and exploration tickets, what usually happens with those after you finish? Are they moved to a “done” column or placed in the backlog or ready to work areas?

Yep, moved into a “Done” column

Very cool. Again, thanks for sharing, that’s helpful!

We categorise buckets and add backlog items to relating additional needs and improvements. We usually smash a load of stuff at once that relate so we don’t bounce around too much.