Design vs. Agile

For some time I have thought about how to better integrate design process into agile processes. You know, any kind of design and for any kind of agile projects, but let me focus this on the digital side — the one that deals with digital product development.

Agile process often cuts epics into stories and stories into subtasks. They would run these through sprints and get a burn-up chart. With mechanical tasks, this makes sense. But for exploratory tasks, like design planning and wireframing, this sometimes doesn’t get in line with the other tasks. Design revisions can take multiple stages and creating new stories for every revision is just pointless.

Therefore, I think we should separate development sprints and design (process) sprints. The development sprints are only for design deliverables that have smaller margin of changes — the ones that developers should actually work with. The design sprints are done beforehand but used to formulate problem-solving, wireframing, prototyping and testing.

This can be as short as a one-week sprint or a two-week or three-week sprint, in my opinion. It engages everyone to think about the product coherently and not touch any code.

As outlined by thoughtbot, it can be a short 5-day sprint:

A Product Design Sprint is a 5-phase exercise which uses design thinking to reduce the inherent risks in successfully bringing products to market. We’ve done six product design sprints so far and have made them a default part of our consulting engagements.

Participating in a Design Sprint orients the entire team and aims their efforts at hitting clearly defined goals. Sprints are useful starting points when kicking off a new feature, workflow, product, business or solving problems with an existing product.

Things will surely change over the course of actual development sprints, but at least we all know the big picture and would hopefully stay on course.