Design and Engineering’s sprints, do they need to be the same?
I often get asked if a Design team’s sprint have to be on the same schedule as their Engineering teams. The easy answer is - yes, ideally it would be great, but what if it’s not possible? What if your development team works on a different cadence or uses a totally different agile model?
Actually, this isn’t a bad thing and here’s why.. Design and Engineering processes are fundamentally different. There — I said it. Don’t get me wrong, it’s possible for both disciplines to work together, but Design and Engineering workflows are different, sometimes very different. It’s like the Yin and Yang.
This Chinese philosophy describes how opposite or contrary forces are actually complementary, interconnected, and interdependent in the natural world. Similarly, Design and Engineering are interconnected and yet have very different workflows. But somehow both work together to deliver an end result. However, that doesn’t mean they have to adhere to each other’s schedule.
If your development team works on their own sprint cycle here are some tips on how to work within that constraint.
Key Steps
- Pick a discipline. Make sure your or your Design team is practicing some form of Agile UX. Whether it be Scrum, Kanban or Scrumban, you must have a consistent work life cycle. I suggest Scrum which you can read more here as to why.
- Prioritized Backlog. Make sure you have a backlog of work including epics and user stories.
- Consistent sprint cadence. I suggest 2 week sprints as it tends to be just enough time to make progress and yet still allows for pivoting without too much loss of work.
- Bi-monthly sprint planning meeting. At the beginning of each design sprint meet with the Developer Lead and Product Manager to review your team’s weeks prioritized work. Be sure to communicate when work is going to be ready for “development”, work that needs to be sized or work that’s coming down the pipe.
- Daily Stand-ups. If your team isn’t doing these start now. I address the benefits of stand-ups in my other article “Choosing the right agile practice”.
- Sprint Demo Day. At the end of every sprint, demo the work that was done. Highlight any work that’s ready to be “delivered” and needs sizing.
- Communicate your plan. Always communicate your plan and what deliverables the sprint will yield. Knowing what’s coming is critical for both parties to plan accordingly.
Key concept
Just because you work on 2 weeks sprints doesn’t mean you delivery work that’s ready for development at the end of every sprint. Sometimes research or getting user feedback can take several sprints. For instance, the graphic below illustrates a monthly sprint cycle for an Engineering team and a two week sprint cycle for a Design Team.
During Sprint Planning and Demo Day the sizing and delivering of design assets can be coordinated with Product Management and Engineering.
In addition, even when both teams are on the same sprint cycle delivery of design assets may vary depending on when work is ready.
Again, communication and planning of the delivery is key in coordinating the flow of work between the two teams.
In Conclusion
It’s ok for design teams to run on their own cycles as long as communication is part of the plan. Like the Ying and Yang - each team depends on each other and needs clear communicate on what they’re delivering and when.
Done right, both teams can actually work fast, produce high quality products, and still work how they want to!
