How Supercell Runs Sprints and Retrospectives

Maria Maunula, a senior producer at Supercell, runs two-week sprints that never change length, each starting with a planning meeting that ends in one agreed goal. Every sprint closes with a retrospective that reviews those goals and last sprint’s actions, then commits to a few new actions, each with a named owner.

Maria works on Hay Day and joined Supercell in 2024 from Rovio, where she was lead senior producer. Supercell is known for tiny autonomous teams called cells; in Maria’s words, its teams were historically 6 to 12 people. As live games grew, teams grew with them, and Maria describes working in hybrid, global teams of 60 to 100 people. Her job is to bring in the processes a team that size needs without losing the bottom-up culture.

How long should game dev sprints be?

Maria prefers two-week sprints, and she cares more about the length staying fixed than about the exact number. Teams that change sprint length from one sprint to the next never build the habit, and the constant change pulls focus away from the work.

“I don’t mind how long it is, as long as it’s usually always the same. So we’re building a habit at the same time. I personally prefer two weeks.”

She gives two reasons for two weeks. Longer sprints are too long to remember: people already struggle to recall yesterday in a standup, so a retro on a three-month cycle asks for memories nobody has. Two weeks also matches mobile iteration speed, where a team should have something playable within one sprint. Maria argues that even a AAA team can break its work into pieces that fit.

For a team new to sprints, she sometimes starts with four weeks, so the meetings take about two hours out of a whole month. “Oftentimes I find that teams actually ask for faster cycles. So two weeks seems to be the sweet spot most of the times.” She plans exceptions in advance: Finnish teams take most of July off, so she may skip a sprint or run one extra-long sprint over the summer.

Who runs sprint planning at Supercell?

At Supercell, the producer runs the sprint planning meeting, but the team decides what goes into the sprint. Maria can suggest priorities, and the team can challenge them.

“Especially here at Supercell, it is different because we are truly bottom up. So there’s no scenario where I would come and say, team, you need to do this.”

The exceptions are time-critical items such as legal compliance, and even then the team hears why. Maria’s part of planning is to show the pool of options from the backlog, flag which are critical, and give the team room to discuss why each one matters now. She also checks workload. If one person signs up for 50 items in two weeks, she asks whether that is realistic or a plan to crunch, and the team agrees on a sensible load.

Planning ends with one clear commitment: what the team will have in hand by the end of the sprint. Maria writes that commitment up and sends it to the rest of the team and to stakeholders, so the retro has something concrete to check against.

How do you run a retrospective that actually changes something?

A useful retrospective ends with a few actions, each with an owner, and the next retro starts by checking whether those actions happened. Maria sees many game teams use retros as ranting sessions and skip the action step entirely.

“That is the point where you actually build your team. That’s where you actually build the trust.”

Maria runs her retros every two weeks on a Miro board themed to look like the game, in this order:

1. Sprint goals. Did the team achieve what it committed to? If not, why not? If yes, take a moment to feel proud.
2. Last retro’s actions. Did the team do what it promised? Her example is a team that blamed Jira, admitted its tickets lacked test notes and status updates, and committed to better tickets. An action stays on the board until it is done.
3. Silent writing on what went well. Three to ten minutes of sticky notes: what went well, what made people proud, what they learned, what was fun.
4. Talk it through out loud. Everyone presents their notes, starting with the good things. Maria doesn’t run anonymous retros, because the point is to build trust: “Some people love to do anonymous retros. I hate them. Just kill them.”
5. Silent writing and discussion on challenges. What frustrated people, what slowed or blocked them, what made the team miss its goals.
6. Actions. Decide what changes: team behavior, tooling for the backlog, or a technical fix. Commit to a few, give each an owner, and publish the list.
7. Vibe score (optional). Each person rates the sprint from 1 to 5, and Maria tracks the team’s average over time.

The owner is the step teams skip most often. “They talk about the right things and they choose really good actions, but they don’t assign anyone to own it. And then that doesn’t happen.” Committing to too many actions fails the same way.

The vibe score gives Maria a trend line for the team’s mood. When a decision elsewhere in the company hurts the team, she can show the people who made it the drop in the numbers. She also sets up the retro board before the sprint starts, so people can drop a note the moment something frustrates them instead of trying to remember it two weeks later.

Teams resist at first, but Maria says many later asked for more retro time once they saw the actions change how they worked.

How often should a game team hold standups?

Maria sets standup frequency by the team’s seniority. A new team with a wide range from junior to senior gets frequent touch points, often daily. Her current senior team meets twice a week, for a 15-minute time box focused on blockers.

As a junior producer, she followed the book and ran daily standups everywhere. Now she asks each team how often it wants to meet. The two weekly standups work because nobody waits for them: anyone with a blocker posts it in Slack right away. Maria also uses standups to repeat important news, since information gets lost easily in a fast-growing team.

A daily Slack thread fills the gap between meetings. People post what they finished, especially work that affects someone else, and flag where they are stuck.

How do you build a roadmap for a live game?

Maria keeps one roadmap for the whole team as the single source of truth for time: release dates, holidays and every sprint, numbered, for the full year. The feature roadmap is separate and changes constantly, because features ship when they feel good, not on a forced date.

“I want to make always sure that we do have one source of truth, one big roadmap for all team.”

The timeline roadmap holds every date that can affect the work, so anyone on the team can check which sprint it is and what’s coming. Maria plans the year’s sprints in advance and treats the document as living.

For features, the team commits to a feature, estimates it and breaks it into smaller milestones to get a release estimate. Then it playtests and iterates, including user testing with creators or tools such as Playtest Cloud. If a feature needs more iteration, it gets it, and each sub-cell updates the roadmap. Maria notes that free-to-play mobile teams have the luxury to iterate in a way many other games don’t.

How do you forecast features in a free-to-play game?

Supercell forecasts outcomes, not features. Each release is a window to give players something relevant and fun, and the team commits to a feature only once it knows what result it expects that feature to deliver.

A/B testing changes the maths. A feature may first reach 5% or 90% of players, so Maria’s forecast looks at the date when it reaches 100% and asks what the result should be then. The team checks every month whether it is heading in the right direction, and adjusts for risk, legal issues or features that didn’t work.

“It’s not the truth. It’s not how it’s going to always go, but it gives us direction, goal, guardrails.”

She sums it up as “educated guessing,” based on data and gut feeling.

Forecasting by outcome needs data to check against. For a new feature, Maria says you may need to build a data pipeline as part of development. For an existing feature it is easier. Her example is the tutorial, where a team should have data at every step to see where players churn and measure whether a fix worked.

Which tools does a Supercell producer use?

Each Supercell team picks its own tools. Maria’s own set comes down to four: Slack, Jira, Miro and Google Sheets.

Tool	What Maria uses it for	Why she picks it
Slack	Team communication, blockers, daily progress threads	She has tried Discord and Outlook; “Slack is the king.”
Jira	Ticket management across sub-cells	Scales to thousands of tickets, works with external partners, security, plugins and automation
Miro	Retros, brainstorming, design boards, her roadmap	One whiteboard for many uses; free for small teams
Google Sheets	Maths, data, sometimes roadmaps or sprint planning	Everyone in the industry already knows how to use it

Maria admits managing many tools is painful. Teams pick tools for different reasons, from habit to growth, and she tries to cut the number wherever she can.

Where do AI and automation help game production?

Most of the production problems Maria and her fellow producers looked at needed automation, not AI. “We actually ended up that a lot of our challenges are actually automation, not AI.”

Her examples are small and practical:

• Assign a ticket automatically when it reaches “ready for testing”.
• Generate release notes from the fix version of a release.
• Flag a holiday bottleneck, such as 10 out of 10 people on a team requesting the same weeks off.

She has seen AI help in only minor ways, such as summarizing retro sticky notes in Miro. Personally, she uses ChatGPT and Claude as a sparring partner, trained on her team’s context, which she asks to challenge her decisions with questions she may have missed. In her words: “I use it to, funnily enough, actually to roast me.”

What should every game team align on first?

Maria’s one fix for the whole industry is alignment on the team’s North Star: what the team wants to achieve and why. She sees unclear goals as the main reason teams fail, whatever their genre or size.

“If you don’t align on that one simple thing, you’re screwed. Your roadmap will not hold on, your team motivation will not hold on.”

She points to Simon Sinek’s “why, how, what” model. The why has to be documented, shared and repeated until every person on the team is committed to the same goal.

The easiest place to start is your next retrospective. Open with last sprint’s goals and actions, end with no more than three new actions, and put a name next to each one.