Welcome to the Jira for Designers series brought to you by Design at Scale™ – Academy. In a previous article, we discussed Scrum for Designers(↘︎Link) and how best to organise your work in the Scrum-based Jira Board. This article will take our exploration even further and look at the Sprint for Designer(↘︎Link).
Just to be clear here – we are not talking about Jake’s Design Sprint(↘︎Link). His work is fantastic and has influenced many designers around the world. The Sprint for Design is a design segment for designers delivering design in complex environments. This minor nuance has a slightly negative impact on the understanding that design sprint is not the same as spring for design in an agile environment. Jake's “Design Sprint”(↘︎Link) solves a quick iteration of one feature, whereas our Sprint for Designers(↘︎Link) can have +50 iterations that have a direct impact on the product or service that is fully integrated with the organisation.

Agile vs Sprint
Agile(↘︎Link) is often defined by the Plan, Design, Development, Test, Deploy, and Review, where the design plays a very small part. No doubt, when translated literally – the designer brought into such an environment will naturally struggle(↘︎Link).
The design function here is to support the development of well-written code.
No brand guidance, colour theory, impact on the customer and so on. It is 9 out of 10 about functionality. The team meat engineering team has defined the environment, language, security protocols, and testing protocols, where to deploy them, and under what SLA – system level agreements(↘︎Link) they deliver their work. On the other hand, the design team (in our case, the designer) would remain empty-handed with questions such as:
- Do we have the Design System? (or at least brand guidelines)
- Do we have the Research? (Objectives)
- Do we have the Persona? (KYC)
- Do we have HLRs? (KPIs)
- Do we have the UACs?
- Do we have NR and news?
- To name a few …
These are the usual preconditions that any design requires to deliver qualitative and quantitative output to any organisation. Whether business(↘︎Link) does provide or allows you to create it, artefacts will define your success.
Let’s continue with the Epic: Search.
Organising the task the following way reduces the length of the task and makes it easy to scan while clearly defining the function. The order of the tasks clearly communicates the dependency of each function and what the function prophecies in the name of the ticket. This way, you can easily read/scan the sprint and get an immediate value out of it.
CPO / SEARCH / Overview (HLR’s + KPI’s + SLA)
UXR / SEARCH / Landscape Analytics
CX / SEARCH / Navigation and Behavioural Patterns
CX / SEARCH / Persona
CX / SEARCH / Wireframes and User Journeys

Sprint and Design Sprint
As mentioned above, both sprints carry the name of design, yet they both deliver completely different increments to the product team. If you are designing in a complex regulatory environment, make sure that the organisation is represented by the business CPO(↘︎Link) and, let alone the development team, use the wording correctly. This will allow you to define what the Sprint – the “Design Sprint” or “Sprint for Design” delivery really means.
In our Design at Scale™ – Academy(↘︎Link), we describe this in great detail with all the dependencies and caveats of who does what and when. As we are limited here, let me let me break this into the following three small subsections.

Outputs, Outcomes, Matters
Design delivery often depends on several internal and external factors(↘︎Link). This way, some of your work can be completed without you, or you might be completing the work that is part of the bigger picture, and someone else will use it. Designers create outputs, and outputs drive outcomes(↘︎Link). You contribute to the organisation's design system; you are creating outputs, and they are used by several other designers on the front line to build products and services. Or the other way around, you are consuming your organisation's design system without ever contributing to it – is that simple.
Either way, the matter defines the relationship. If you are in a smaller team(up to 10 people), you’ll be defining both, and it will be in your interest to prevent duplication. From the organisational perspective, you’ll define outputs and assign them a specific time and space during your work day. That way, you can control what matters – the velocity(↘︎Link), in other words, the speed of design delivery. This simple coefficient will help you to communicate your efficiency while equally helping you to get more resources when the work and demand for your services grow.

Daily Routines
This brings us to design specific daily routines. I’m afraid you’ll never get away from stand-up (↘︎Link). Undoubtedly, this is the one that is non-negotiable.
Daily stand-up allows the entire team to gather and share the progress on all tasks and dependencies(↘︎Link).
In the week, there are two events that take only ½ hour but keep the team in shape and motivated when complexity or boredom arises. These two events are Sprint Planning(↘︎Link) and Show and Tell(↘︎Link).
Sprint Planning
Sprint planning helps the team to decide what is important and what has to be delivered this week based on the priority. Let alone what makes sense and what fits in one week of work for your dedicated design resource/team. This way, we can easily drive the momentum and shift resources where needed.
Show and Tell
Some design teams have a formal delivery. In my 20-year practice, it has become more efficient to have “Show and Tell”(↘︎Link), where we can present what has been done in a more laid-back fashion and make the official delivery less official and more celebratory. That way, the team celebrate the success of the delivered artefact, and when the Bugs(↘︎Link) arise, we just fix the bugs based on UAC’s(↘︎Link).
This drives better morale and greater relationships in your organisation.

Daily Drops – Make Things Happen.
Lenny Krawitz, in one of his songs from the 90’s, sings – My mama said, Don't take more than a mouthful …(↘︎Link). I found it great advice for a daily task that we call daily drops. At the end of the day, when we drop the mike on the work, we need to share the impact with the rest of the (internal) team. That way, the increment will be recognised(↘︎Link) and acknowledged(↘︎Link).
The inner team can use it and expand on it. External teams will be informed that the increment on the task was delivered, and therefore, the “progressive” development can continue without any further impact. This way, we reduce RAG Reports(↘︎Link) to a minimum, as we’ll have everything in Jira ready for tomorrow morning's stand-up(↘︎Link).
One little caveat for remote and co-located teams – the drop can also mean that the person on the other side of the world can pick it up and continue development in our case design. And when you return to the office, their work will be done, and you can continue again.
In 2011, I was fortunate enough to be part of a super-talented team that has offices in London, Singapore and San Francisco. Our teams collaborated at the speed of light – literally, I’ve never seen such team synchronicity and harmony. We had overlap for an hour or two, during which my colleague's Drop-Off was my Stand-Up, and my Drop-Off was someone else's Stand-Up – the design symphony.
Happy scaling through design!
Hey, I’m Jiri Mocicka.
London-based Design Director, Trusted Advisor and Author of Design at Scale™. The method that empowers individuals to shape the future organisation through design.
If you have a question, join our Community and reach out to like-minded individuals who scale design propositions. An online Academy can help you to find your feed in teams of 01, 10, and 100, supported by Grid Magazine and Supply section, where we weekly bring more insights on how to become a design leader in your organisation