Mono has closed its doors. Read more in our blogpost.

Go to main content
  • Johan Ronsse

Design work doesn’t fit in a sprint planning

Most software teams work with agile methods, with the base logic of sprints, and then adding in their own flavor to it to cover how they do grooming, whether they assign points to tickets etc.

When a design firm like ours is hired, there is often an attempt to plan the design work to be in sync with the development sprint planning. In my opinion, no attempts should be made to fit design planning into the sprint planning, because they are two different things.

Design is about figuring out the problem and shaping a solution.

Development should be about execution and making things work. If you are solving the problem in development, something is wrong.

Now, because of the typical team composition and imbalance of teams (too little designers, we would say), design happens anyway. It’s just not always done by designers.

It’s sometimes done by a front-end developer. It’s done by a quick mockup in Powerpoint. It’s done by a description in Jira ticket. It’s done in a myriad ways. And that’s totally fine.

To restrict decision-making to “designers only” would be a gross overstatement of our capacity as designers. It would also simply not work, because if I take our clients as a measure we can count 1 designer for every 12 developers. So if decision making would be restricted to design, you are creating a huge bottleneck there.

Instead, decision making happens as a group. And each person has their own specialty. The developer knows the complexity of the codebase. They know the kind of queries they’d have to write to do the data wrangling work. The UI designer knows how the current problem fits into the existing design system, and how much extra work something would incur. The customer support person knows what the customers were recently asking about. The product manager knows a little bit of everything and tries to make the right decision based on that.

Quite often decisions are made without involving the user at all. That’s a problem in itself and probably a blogpost in itself. But what I want to say in this one that you shouldn’t treat design work as part of a sprint planning. It is a separate process.

Deliverables from the design work could be used during the development work. Design can play a role in development work by giving feedback and handling a bit of QA. Development can play a role in design by making something that’s truly interactive – a prototype that can be tested.

But if we see design as problem solving, and take a step back from the day to day work, it’s clear that the design process has an entirely different timeline than the development process. To try and align these is a house of cards that will fall down pretty quickly. I’ve seen attempts and it has never worked. So don’t.

Johan Ronsse

About the author

Johan Ronsse is an interface designer who is trying to find the balance between aesthetics and usability. He tweets as @wolfr_2.

Subscribe to our newsletter

Receive blog highlights and fresh insights into UX/UI and front-end development.

1 thought on “Design work doesn’t fit in a sprint planning”

  • No avatar

    19 Oct 2019 at 09:19

    I agree that design is needed to shape the right product. But to create products right, a lot of trade offs need to be made. Also when you are coding the thing. Hence, a designer should be involved in Sprint planning to balance discovery and delivery work. It also works the other way around: to involve developers in the discovery. It is a messy thing, but communication and collaboration between design and development kinda solve this problem. But getting collaboration smooth is hard :)
    I am willing to help if you want.

Leave a comment

Your email address will not be published. Required fields are marked *