Americas

How We Organise and Empower Our Global Design Team with Internal Sprints in Jira

January 07, 2021

By Monstarlab

 

How implementing internal team sprints helped our design team organise and structure internal tasks for better transparency, efficiency and distributed ownership.

The Monstarlab design team is spread across the globe — from Copenhagen to London to Dubai — so our work is decentralised by nature. We implemented this ‘internal team sprint’ approach before the pandemic hit, back when the only thing we associated with the word Corona was a cold beer on a hot summer day (Oh the blissful ignorance!).

Nevertheless, with this new reality where our team has been 100% remote, the usefulness of this approach in helping us to work efficiently together apart, while still feeling like one cohesive team, has been put to the test… and it has passed with flying colours!

Our challenge

Working in an agency means that client projects are often prioritised leading internal tasks to be put on the back burner. Designers are assigned to different cross-functional teams for projects, and when our team members finally did have time to work on internal stuff, we had no structured plan that allowed each of us to know what task to take on next, or what other team members were working on.

The main reason we choose to try out a sprint-format was to structure our internal tasks, but also to create more transparency around who does what and why. We wanted a smart and easy way to include all team members in that conversation and not only team leads. Furthermore, time restrictions in our schedules meant that we needed a flexible and low-maintenance way to do it.

Before our team sprints, our internal tasks were primarily driven by individuals. A big drawback from that was the missing transparency. It was difficult to know what team members were working on because we work from different parts of the world. The sprints have really helped push the internal agenda and keep everyone in the loop.

– Søren Clausen, Visual Design Director, Monstarlab

The ‘Internal Team Sprint’

We were inspired by the sprints we often use for our client projects when we created our internal team sprint. However, we needed to adapt this framework to fit our team’s needs.

The following section provides a step-by-step account of how we approached this challenge, and what we learned from it.

What is a sprint?

A sprint is a time-boxed period where a team works to complete a specific amount of tasks. Large projects can be broken into smaller pieces, and progress is reviewed along the way. This allows for the plan to be modified to respond to changes.

Set your team up for successful sprints

  1. Define your sprint timeline

As we only work on internal tasks when time allows for it, we have extended the duration of our sprints to be 30-day cycles instead of your typical 2 weeks. This long-term perspective makes it more realistic for us to get tasks done without increasing pressure on each team member. To stay in the running analogy, you can say that the conditions we work under have made it necessary for us to adapt the approach to be more like a marathon than an actual sprint.

How you adjust your timeline should be based on a realistic estimation of the time it takes for all team members to complete a given number of tasks while ensuring that cycles are not so long that team members don’t get the support they need from the mid-cycle touchdowns. For us, breaking tasks up into smaller but more achievable components has helped keep motivation high and ensure delivery on tasks.

  1. Choose the right organisational tool

After agreeing on our timeline, we structured our tasks in Jira, which is an awesome digital tool for organising projects. You might already have a tool your team knows and likes, but if you’re in the market for a new organisational tool that is designed to aid you in agile sprint-planning, I can recommend Jira. It has a flexible structure which means it can be customised to your needs, and it has the features needed to facilitate sprints.

 

  1. Create your epics and backlog

A good framework for sprint tasks is divided into some kind of structure of core categories that define the tasks that live within them. In sprint terminology and Jira, these are called epics. As you can see from the picture of the epics in our roadmap below (how it looks in Jira), we have defined them according to the different types of tasks we work on.

The epics are closely related to the goals we have for our team to strengthen it internally and externally. Structuring our tasks within these epics has allowed us to keep track of how much work we actually put into the different areas after each sprint.

Once these epics were in place, we started creating tasks within each epic. The accumulated list of tasks comprises our backlog, which you can see below. The backlog is a living list that is constantly added to and deducted from when tasks are moved from the backlog into an active sprint phase. One of the perks of having a shared backlog is that ideas are more rarely “lost” as all team members can add ideas at any point in the process. These will then be discussed and prioritized during the sprint kick-off (step 4).


Ready, Set, SPRINT

Once we set up the framework above, it was incredibly easy to work with, maintain and adjust as we gained more experience and reflected on each sprint.

  1. Sprint kick-off

To kick-off a 30-day sprint, we have a team meeting, also called a sprint planning, where we discuss the tasks in the backlog, prioritize them according to their importance and assign the ones we want to include in the sprint to individual team members.

Tasks are assigned based on the time, interest and capabilities of each team member, and we don’t have any fixed number of tasks that each member should take. As most team members often have limited time for internal tasks, and because this does vary a lot from month to month, we’ve made it an opt-in concept to create more flexibility.

Not all tasks in the backlog make it into the sprint, but luckily, that’s exactly what the backlog is for. Once a fitting number of tasks are assigned, we officially kick-off the sprint with the sprint-function in Jira that works as a timer.

 

  1. Mid-sprint touchdown

Midway in our sprint (2 weeks in), we have a touchdown with the team to have an update on the progress that each team member has made on their tasks. Having this collective midway reflection allows us to get feedback, flag challenges and discuss solutions with each other.

The agility of this method allows us to adapt our sprint to the changing circumstances we often operate under being consultants. For instance, we can redistribute tasks to avoid bottlenecks or choose to carry the tasks over to the next sprint.

Retro and repeat

  1. Sprint retrospective and new sprint kick-off

Every 30-days when a sprint ends, we have another team meeting with a dual purpose.

Firstly, we have a sprint retrospective where we discuss the sprint that has ended and the completed tasks. We discuss how it went, learnings, challenges and successes. We also look at how we’ve spent our time in terms of different epics and discuss if we should shift our focus for the next sprint to make sure we move in the right direction.

The second part of the meeting is the kick-off of the next sprint. Here, we repeat the process of step 4 and start all over again with new and carryover tasks we want to put into our next sprint… and the cycle goes on and on.

Outcomes

The transparency we’ve achieved from systematically tracking our internal tasks in Jira and working in sprint cycles has enabled us to break bigger projects down into realistic bites so that we constantly progress. Everyone is contributing, and we have fewer bottlenecks now that tasks are distributed better.

Utilizing Jira and sprint ceremonies for our internal tasks has really improved visibility of tasks, ownership and progress in the creative team. Any type of team could benefit from this type of transparency, and we are currently exploring how this could look for other teams in Monstarlab.

– Niels Truong, Chief Strategy and Consultancy Officer at Monstarlab

In our team, we’ve been able to identify the epics that need more attention, and the shifts we should make to reach our long-term goals. Examples of this could be:

  • Spend more time on strategy and creative brand to enhance the value-offering of our services towards the market, or
  • Spend more time on education to ensure that our team is constantly upskilling and staying inspired by sharing knowledge, taking courses etc.

Moreover, even though each of the team members in our team still spends most of their time working on other projects in cross-functional client teams, we’ve found that implementing these internal team sprints has helped us feel more like one team with a common purpose.

 

You may also like

January 14, 2021

When to Use the Design Sprint (and when not to)

A framework for deciding when to apply the Design Sprint and when to apply the Discovery Sprint By Linn Elster, Associate Director, Innovation & Strategy, Monstarlab.   Over the past years, I-as many other ...

Design sprint

In order to improve this website, we use cookies. For more information please read our Terms of Service. To agree with the use of cookies on this website, please click the ‘Continue’ button.