Welcome to the Jira for Designers series, brought to you by Design at Scale™—Academy. In a previous article, we discussed Kanban(↘︎Link) and its advantages for an agency or product design team. In this article, we’ll take our exploration even further and look at Scrum(↘︎Link) and its benefits for designers who bravely choose the production line.
The time matters; given the fact you have chosen the front development line telling something about yourself as a designer, you are a real problem solver(↘︎Link). The assumption here is that your colleagues in the central team have done their job correctly and already figured out the Brand proposition(↘︎Link), Brand direction(↘︎Link), Messaging(↘︎Link), Tone of Voice(↘︎Link), Design System(↘︎Link) and overall Design Architecture(↘︎Link) for the product or service you are creating in your organisation.

Scrum vs Agile
Why Agile and why Scrum?
Agile, in its own way, is combined with principles, methods and techniques where Scrum has very specific time-related objectives(↘︎Link).
Scrum organises itself in Epics, Stories and Tasks, helping designers recreate a specific behaviour scenario. Let’s stay with Search for now. If the Search is the epic, there are several Stories to be fulfilled. In BDD, we use the following structure.
“As a legitimate user,
I shall be able to <ACTION>
leading to <RESULT> (customer objective)
generating the <RESULT> (business objective)”.
Allowing us to do the following: “As a legitimate user, I shall be able to;
- LOCATE search
- ENTER the search query
- REFINE search query
- RECEIVE the result of my search query
- REFINE the result
- FILTER my search query
and so on. This way, every designer will understand what needs to be designed and what the reason behind each screen is. More importantly, the entire product team understands the context of the proposition. Allowing all team members to collaborate on one ticket. Please see the 80/20 design development diagram below.

Why designer should care
Simply because it makes their life better, do you believe it?
(Before continuing, you can please read one of DaS™– GRID Magazine articles describing Proactive vs Reactive Culture↘).
Here is a simple example: In the very first meeting, when we define the proposition, our engineer leaves with ten answers and starts working on connecting databases, setting the environments and so on. Where we designers leave with 100 questions – who the customer is, what are their objectives, and why do they simply do what they do in the product anyway? By understanding and defining the problem statement with BDD – Behaviour Driven Development(↘︎Link), we designers acknowledge that our understanding is not different to our engineering colleagues and we speak the same language. Therefore, the creation of a partnership and connected culture is required for an integrated smooth delivery(↘︎Link) to be established.
If your team throws the design over the fence without knowing its purpose, you are most likely creating a delivery spike – meaning someone on the other engineering side of the fence needs to take your work, review it, understand it, check it, compare it with and add into an existing work stream and then and only then schedule for the development. By using common language as a starting point, we designers can reduce the overload of product teams by more than 27%, leaving your team with 18% more time-in-year delivery (which is 5 weeks of work, 180k from £1m operational budget).

How to read it
There are plenty of YouTube videos describing the Jira Environment(↘︎Link). Certainly suggest you find what is working for you the best. I genuinely find engineering explanations more insightful than the ones from the product people – especially if you find yourself countlessly delivering design propositions without product personnel. Then, you realise that self-managed teams are the future of delivery.
Starting from the left Release, Epic, Story:
Release
We are mimicking the development cycle, which is usually on quarterly releases. Y25 Q1/Q2/Q3(↘︎Link) and so on is pretty obvious. If we have multiple teams, such as design systems or user research, it comes down to Y25 UXR Q1 or Y25 DS Q1. This shouldn’t be more complicated also. Do not forget that this sequence or nomenclature better said is circulated on weekly review as a RAG summary report(↘︎Link).
Epic
Epics are slightly different. I first ran the Epic exactly the same way as the development until we all realised (a 100+ designer team) that we were spending more time adding labels for design than actually doing design. If your team is looking at velocity and optimisation, this factor is the holy grail of the improvements from the retrospectives.
Now, here is the difference:
Our epic was adjusted to the function. CPO, UXR, DS, UI, CX, MOT, and XT will be used to align all tasks for the function(↘︎Link). This firstly increased the transparency about what feature we are delivering and, secondly, how these features are crossed and depend across the delivery.
This allowed us to improve our design delivery. CPO started planning based on insights and not only on priority. UXR became a foundation for our CX and UI workstream, which helped significantly with reprioritising tasks and increased productivity by an additional 18%.
Story
By far, the biggest impact was the names of the stories. I know that perhaps every Scrum Master and Product Owner has their own way, and we all believe these ways are correct. Nevertheless, we need to bring transparency across the multiple teams; therefore, our content team ran an exercise and came up with something we have already been using in different contexts.
UXR / SEARCH / Landscape >
FUNCTION / FEATURE / Task
This way, we’ll have the following tasks in one week:
UXR / SEARCH / Landscape
UXR / SEARCH / Insights
UXR / SEARCH / Impact Study
CX / SEARCH / Navigation Patterns
CX / SEARCH / Behavioural Patterns
CX / SEARCH / Wireframes
CX / SEARCH / Persona
CX / SEARCH / Content Model
CX / SEARCH / Filtering
UI / SEARCH / Content Exploration
UI / SEARCH / Brand
UI / SEARCH / Media
UI / SEARCH / Controls
UI / SEARCH / Filters
UI / SEARCH / Listing
And so on, you get the picture. This way, the CPO can clearly identify and understand that one feature is fully developed and can be fully tracked from initial idea to final delivery.

Where can you find your stuff?
The most common phase in every remote team is “Where do I find X?”(↘︎Link). Sadly, only very few businesses actually spend time defining these deltas; they would rather spend 2-5 minutes each and every meeting discussing the very same thing.
Simple math:
5min x 5 days x 4weeks x 11 months
(assuming you take some holidays) = 1100 minutes (CCA 20 hours) wasted on finding the basic docs.
Forester reported that every 1k people organisation wastes 30-40% productive time on locating the right data (files) to make an informed decision. Take a moment and ask yourself and the business what the number is in your organisation.

Designers in Agile Environment
The designer in an agile environment used to fight three different gravities. One is the business – no one ever sees it, but we designers somehow develop respect and absolute abandonment without questioning it. The second one is the engineering – it can’t be done. After referring to the fact that it can not be done in the time and space we have, the synchronicity between development and design is essential. The third is the design itself. Let’s face it: every designer, in some cases, is trying to reinvent the wheel and push for brand, animation, expression, tone of voice or make it pop a little – you know what I mean. The delivery line is always about shipping – if you can improve it in a defined sprint, do it – if you can not, do not stress it and improve it in the following sprint.
And that is why the very next article will be about Sprint for designers – not a Design Sprint!
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