Series: Kanban to Scrum Transition | Part 2 of 4 | Documenting our team’s structured evolution from Kanban to Scrum
Establishing a Foundation for Change
After identifying that our current process was not serving our goals, the next step was not to “install Scrum” but to create shared understanding. Change doesn’t stick without meaning. So we opened a FigJam board, set time aside, and asked: What do we want to achieve by moving to Scrum?
We started by anchoring the conversation around our team goals: autonomy, transparency, routine, and efficiency. Each of these emerged from actual feedback, not theory. We didn’t want Scrum because it was popular. We wanted it because we believed it could address our specific needs.
What Does Success Look Like?
We didn’t just list goals. We asked: How will we know we’re getting there? This led us to co-create visible, specific success indicators:
- One sync touchpoint per day, no more.
- Transparency on delivery scope and blockers.
- Epics that move forward every sprint.
- Sprint reviews that close feedback loops.
These weren’t metrics for reporting up. They were for us. They were proof that our system was improving and supporting the way we wanted to work.
Anchoring in Scrum Values and Pillars
We also didn’t assume shared knowledge. In our alignment session, we asked each person: What are the pillars of Scrum? What values do you connect with?
We talked about Transparency, Inspection, Adaptation — not as theory, but as behaviors. Then we explored the values: Commitment, Focus, Openness, Respect, Courage. And asked: Which value resonates with you most, and why?
That conversation alone changed the tone of our transition. It moved us from compliance to conviction. Scrum wasn’t something we were applying to the team. It was something we were choosing as a team.
Co-Creating Definitions of Ready and Done
Another critical session was dedicated to building our Definition of Ready (DoR) and Definition of Done (DoD). These are often introduced top-down — we chose the opposite.
Using FigJam, we mapped out what we need to start work with confidence. Things like: clear background, acceptance criteria, design links, tech dependencies identified. That became our DoR.
Then we did the same for Done: logs created, translations verified, dashboards updated, tested in staging, PO review, production deployment.
Having those visualized together made accountability collective — and gave engineers more confidence when picking up work.
Designing Our Scrum Plays
In the same session, we also mapped what each Scrum ceremony would look like for us. Not just what the guide says, but how we wanted to do it. Sprint Planning, Review, Retro, Refinement. Who owns it? Who facilitates? What’s the outcome?
We were no longer just “switching frameworks.” We were designing a new way of working. Together.
And in Part 3, I’ll share how that design turned into practice — by coaching every engineer to lead the process.
# Team agreement born from this session
echo "Sprint ceremonies are owned by the team and facilitated on rotation." >> team-agreements.txt
Previous in the series: Part 1 - Recognizing the Need for Change
Next in the series: Part 3 - Coaching Engineers to Lead the Process
Kanban to Scrum Transition Series:
- Part 1: Recognizing the Need for Change (Oct 27, 2022)
- Part 2: Aligning Goals, Metrics, and Shared Understanding (This post)
- Part 3: Coaching Engineers to Lead the Process (Nov 10, 2022)
- Part 4: Lessons Learned and Continuous Improvement (Nov 17, 2022)