Curious as a designer on a scrum team, do you have a separate backlog for design tickets? Or do they live in the overall “Backlog” bucket?
Thread
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…
Just-in-time Design
matthewstrom.com
I think the context here matters as well— if it’s the iterative update of the existing product, then yes, just in time design is perfect. But if it’s the very first version or a major update/overhaul, we have to design ahead of time to make sure everyone is on the same page.