From Process Drift to Deliberate Scrum

At Spotify we aim for “aligned autonomy”: teams agree on what needs to be achieved but keep the freedom to decide how to get there. In practice, that latitude only pays off when a team puts real effort into shaping its own way of working. My squad discovered the hard way that autonomy without a coherent process just produces friction.

Our team had been pulling pieces from the Scrum framework — stand-ups, two-week sprints, retros — without connecting them to the principles behind Scrum or treating them as one integrated system. The result was a telling lack of structure: meetings felt aimless, sprints routinely went unfinished, and our product manager couldn’t reliably predict what would ship. As engineers, we had little sense of how daily tasks mapped to quarterly objectives or how close we were to reaching them.

We set three goals for any process change:

  • Continuous improvement: make it easy to understand our work and spot where to get better.
  • Shared understanding and transparency: anyone on the team should know what work is happening and why.
  • Confidence: plan our trajectory and communicate realistic expectations to stakeholders.

Committing to the Full Framework

An Agile coach started by walking us through an assessment of our current practices. We liked Scrum, but we weren’t using it as designed. The coach helped us see how each element of the framework supports the others, and we agreed unanimously to adopt Scrum “by the book” — the entire framework from the Scrum Guide, not isolated pieces of it.

Backlog Refinement

Before the change, stories were often unsized when they entered a sprint, so we had no real measure of how much we were committing to. We now hold a weekly backlog refinement meeting, alternating between:

  • Coarse refinement: we examine tickets, ask questions, and build a collective understanding.
  • Fine refinement: we assign story points to those tickets.

This way everyone has a chance to ask questions and grasp every ticket before it’s committed. We know the volume of work entering each sprint, and we can compare points completed across sprints.

Sprint Planning

Previously, planning consumed most of its two hours with people reading tickets and negotiating which ones mattered. Now that the backlog is refined and prioritized in advance, planning is straightforward: we walk down the queue of pointed, discussed tickets and do any final subtasking to clarify the actual work. After each ticket we pause and ask whether the team can realistically take on more. We end with a sprint of fully subtasked stories that everyone understands and believes we can deliver in two weeks.

Sprint Review

The retro had been a vague discussion of what went well and what didn’t. We weren’t evaluating completed work against product priorities. In our new 30-minute sprint review we demo finished features and ask:

  • What work did we complete?
  • Is there anything we need to extend or add?
  • Did we discover any tech debt?
  • Are we on track for our longer-term goals?

That gives us a chance to regroup and re-prioritize for the sprint starting the next day.

Retro

Our retros used to produce notes on many topics but no real plan to change anything. Now we still collect notes, but the team votes on a single issue to spend most of the session discussing and solving.

Now, our retro format takes us step-by-step from ideation at the beginning, to the refining of a single idea at the end.

By the end we have one implementable action item we can track over the next few sprints. These items let us actively resolve pain points and move toward continuous improvement.

Stand-ups

A simple addition has made our stand-ups far more useful for prioritization and unblocking. At the end, everyone answers on a scale of 1 to 5: “How likely are we to complete this sprint?” Each person holds up that many fingers. If anyone shows three or fewer, we open a deeper discussion. This surfaces problems early — even ones only one person has noticed — so we can swarm on them.

What Worked for Us

If you’re considering a similar process overhaul, these four practices made the biggest difference for our team:

  1. Try a system holistically before adapting it. Agile frameworks are deliberately designed. Run all the parts as intended first, then fine-tune the nuances to your context.
  2. Ask the “stand-up question.” Checking confidence in finishing the sprint gives everyone a chance to voice concerns and suggest fixes early.
  3. Focus retros on one issue. Vote on one or two topics so there’s room to brainstorm concrete, actionable solutions.
  4. Plan sprints you can finish — and commit to finishing them. Build in decision points during planning where team members can decline more work. Right-sized sprints and follow-through make the whole team run smoothly.

The results were tangible. We finally got the feeling of finishing a sprint and celebrating the work. We gained confidence when reporting deliverables to stakeholders. Backend and frontend engineers became more T-shaped as we paired up to hit sprint goals. Average time to complete a work item dropped from 8.1 days to 3.9. We increased our product load from one product to three and tripled our monthly active users — all without adding engineers.

Recommitting to the principles behind an Agile practice illustrates a broader theme at Spotify: finding the right level of alignment to make autonomy work. By adding structure through a full Scrum adoption, we got clearer about our work and stayed aligned on shared goals — and we finished the process with more pride, direction, and ownership of our success.