How we use Scrum to deliver value for our partners

What is Scrum? Our Agile Delivery Approach

At Motion 12, we believe that using Agile project management is essential to delivering results and value for our partners, that’s why our Development Agency uses a tailored version of the Scrum delivery process to meet the unique needs of projects.

The term “Scrum” derives from the English game of rugby, where Rugby players work together in a team to move the ball down the field. Jeff Sutherland and Ken Schwaber used this as a metaphor to coin a framework that promotes collaboration, adaptability and continuous feedback within teams, enabling teams to develop and manage complex projects through short cycles called sprints.

Utilising an adapted “Scrum” framework allows us to deliver Digital product development for clients/partners in clear, time boxed sprints which means regular process updates and working software features every week. Due to us using an adapted “Scrum” framework this also means we remain responsive to any urgent issues that our clients may come up against reducing delivery risk and improving time to value. In this article, we explain what Scrum is, why we use it and how we’ve adapted it at Motion 12, from tooling and task structure to sprint planning and delivery.

Why We Adapt Scrum at Motion 12

At Motion 12 while Scrum provides a strong foundation, following the framework down to a tee doesn’t always align with the realities of agency work. On a daily basis, our partners often require:

• Ongoing support alongside planned delivery
• Fast responses to bugs, outages, or security issues
• Flexibility to accommodate shifting priorities

To meet these needs, we’ve adapted Scrum to balance structured delivery with planned capacity for reactive work. This ensures we can deliver against sprint goals while still supporting partners when it matters most.

Choosing the Right Project Mangement Tools for Agile Delivery

In the Constantly Evolving Processes blog, we discuss our previous use of “ClickUp”, the project management software. However, the constant overload of new features within ClickUp quickly became confusing, making it far too complex for us to schedule tasks in a way that aligned with the Scrum framework: it wasn’t sustainable for us and became overwhelming for scheduling projects. Fast forward to 2024 and our lead software engineer, Jake, completed extensive research into Jira’s most recent iterations. Although Jira has always been opinionated with its workflow, its now modernised functionality and UI allowed our team to increase productivity through adopting the software’s workflows.

Our Custom Jira Integration

Firstly, the biggest game changer for Motion 12 was that our development team created a custom integration that gives us the ability to link specific commits and builds within our GitHub repositories. This integration allows us to:

• Link Github commits and builds within Jira Tickets
• Track progress from task > code > deployment
• Have visibility of a full audit trail across the delivery lifecycle
  

As a result, all work is scheduled and managed in Jira while developers and project managers have complete visibility of progress, commit history and context. Tickets can include documentation, images and videos, improving clarity and collaboration.

We also use Jira Service Desk to provide partners with a dedicated communication channel. This allows clients to raise queries or requests directly via email, ensuring transparent and easily findable communication throughout the project lifecycle.

Our Scrum Delivery Process at Motion 12

1. Project Scoping and Task Creation in Scrum

Every project starts with collaborative discovery sessions, a core part of our Agile project scoping and delivery process, with our clients, where together we define:

• Project Brief
• MVP requirements
• Key Milestones
• Deliverables

Once these have been defined, we create an initiative in Jira which we use as the highest level container that holds all project information.

Within each Initiative, we create Epics. These then represent the major sections of the project such as:

• Project Management
• Strategy
• Design
• Development (Containing all blocks from designs)
• Testing
• Feedback & Fixes
• Launch to Production

An Epic contains a large body of work which is then broken down into multiple Stories and Tasks.

• We use a Jira “Story” as concise, user focused descriptions that outline who needs something, what they want and why it matters. They often follow the format:
  “As a [user role], I want [an action] so that [a benefit/value].” A story typically represent work that will take a few hours to complete and feed into project action points and Epics.
• Tasks are smaller, actionable items that usually take minutes to complete or do not need to be associated with an Epic. They are used for quick actions or supporting steps that don’t require the full context of a Story.

2. Backlog Management

Once a full project has been mapped out, or we may be just working on individual tasks for clients/internally we then add these to our project backlog with as much key information in there as possible before it is added.

3. Sprint Planning

Every Thursday morning, we hold a sprint planning session where the team reviews tasks and projects in the backlog. We create a live document in Confluence (Jira’s linked document application) to collaborate on actionable sprint goals related to tasks that must be completed.

4. Task Allocation

Tasks are moved from the backlog into the sprint. Within the sprint, we:

• Add time estimates to tasks
• Assign team members
• Specify the team responsible (developers/design for example)
• Set due dates and priorities (urgent etc)

You may be wondering how the time estimates relate to the sprint, we have calculated all of our available hours for the week for all the team members. The time estimates are then used against team members available hours so we know how much time available there is for reactive tasks throughout the week.

5. Scrum Adaptation for Reactive Work

Each team member belongs to different teams; developers (scheduled and reactive), designers, project management and business development. Unlike traditional scrum, we allow time for reactive tasks within the sprint to support partners, such as unexpected bugs, outages that require development support, bot attacks or quick design/frontend development tasks.

6. Timelines and Capacity Views in Jira

Capacity View

Firstly, as we’re working through the sprint planning session, we will assign tasks to each team with the time estimates, start dates and due dates set. Whilst we are assigning these to the teams, we navigate over to the capacity view to ascertain how much capacity and available hours each team currently has before we carry on adding tasks.

To determine the priority of tasks to schedule in the sprint, we will discuss client deadlines, the priority of tasks and the goals set to meet MVP/client objectives. This allows us to triage the most important tasks and ensure these goals are completed throughout the sprint.

Assignee Capacity Review

Following the scheduling of tasks within the capacity view (teams), we will then view the Assignee Capacity View to ensure that each individual team member has not been assigned an unmanageable workload. We can then visually see the tasks they are working on to check there are no blockers throughout the week and that all goals and tasks are set for specific dates.

In the daily stand-up, we review the timelines and tasks in the morning to discuss solutions for any blockers.

What Does a Motion 12 Sprint look like using Scrum?

Daily Standup to Discuss Tasks for the day

Every morning we hold a 5-15 minute daily meeting to answer the following questions:

What did you get done yesterday?

Do you have any blockers/questions?

What will you get done today to ensure you achieve your sprint goals?

These questions are absolutely essential for us as a team because they help ensure we all stay aligned and meet our sprint goals for our partners. How? By giving everyone visibility into current challenges, they allow team members to collaborate, offer support and suggest solutions whenever blockers arise.

Beyond that, we maintain an open line of communication, whether we're in the office or working remotely on Teams so any member of the Motion 12 team can reach out to another for help, guidance or clarification at any time. This constant connectivity strengthens our teamwork and keeps our projects moving forward.

Deployments

Throughout the sprint the team will complete multiple deployments across different projects, deploying from staging for user testing on beta versions. We will then receive feedback from Motion 12 Internally and also stakeholders from different partners we work with. This is also why we open up reactive hours to schedule tasks in for any feedback fixes.

Sprint Review and Retrospective

On a Wednesday before close of play the team will collaborate in a Sprint Review session where we all review statuses of all tickets to mark as many tickets as Done, to then close the sprint and create a retrospective. The team will then use the retrospective with reflective practice to decide on one thing the team should improve on in the next sprint.

Delivering Value Through Agile Partnership

By combining Scrum principles with reactive adaptation, Motion 12 delivers structured, transparent and flexible digital projects. Our approach ensures predictable delivery while remaining responsive to change helping our partners solve issues faster, reduce risk and achieve meaningful outcomes.

If you’d like to learn how Scrum and Agile project management could support your next digital project or MVP, get in touch with the Motion 12 team.

References

Website: https://www.scrum.org/resources/scrum-guide

Website: https://www.rebelscrum.site/post/why-scrum-is-named-after-rugby

Book: https://www.penguin.co.uk/books/418189/scrum-by-sutherland-jeff-sutherland-and-jj/9781847941107