Transitioning from Scrum to Kanban "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs 23 June 2017 True Agile, Kanban, Organisational Transformation, Scrum, stakeholders, Mind the Product Mind the Product Ltd 934 A new kanban board, at the start of the transition from Scrum Product Management 3.736

Transitioning from Scrum to Kanban


We here at, creators of Hubble, have recently moved from a Scrum to a Kanban software development approach. The driver behind the move was to improve the speed of business delivery and quality of the delivered product. The process seemed to go smoothly, even though the teams are distributed and have varying skill levels. In this short initial retrospective on the transition, I look at some of the factors that have helped and the potential for further improvements.

Starting Point

Our teams were already experienced in Agile development and were working in two week sprints, with a regression test and proposed release at the end of each sprint, but the business stakeholders were still concerned about the speed of delivery. They saw a development team working hard, but not delivering the features and quality improvements needed by our customers. 80% of our proposed releases did not make it to customers, because they contained unacceptable defects. We decided to move to a Kanban approach, so that we could focus on improving the flow (Kanban Core Practice 3: “Manage Flow”, Mike Burrows, Kanban from the Inside, Part I introduction), making it easier to identify and resolve the unacceptable defects quickly and not hold up the releases. We also took the opportunity to move from TFS to Jira as our lifecycle management tool.


We have several cross functional teams working on the same backlog of work, but they have different areas of expertise. Ultimately, we’d like them all to pick up the next most valuable items from the backlog, but this will require some skills transfer. We’d like to reduce the amount of time spent in regression testing, but we’ll also need more of our testing automated. We’d also like to have feature planning sessions when the teams run out of work but, for now, managing the bug backlog means that we have to discuss and adjust priorities more frequently. These are our longer-term goals, but the steps we’ve put in place mean we are heading in that direction already.

Kanban Training
A team going through training on Kanban principles


Several key decisions have made our path to Kanban quite smooth:

  • Commitment from the top of the organisation. The move from Scrum to Kanban is supported right up and across the organisation. The business stakeholders are patient and supportive.
  • All teams trained on Kanban. Everyone was professionally trained over a period of a few weeks, so we all had the same message and understanding.
  • Used one team as guinea pig. We experimented with our first Kanban board by moving one self-contained team. Then used what we had learned to smooth the process for the remaining teams who all shared the same backlog.
  • All 4 teams moved within 5 weeks. After the first team migrated, we moved one team a week so all four were using Kanban. This minimized the period when we had two different systems.
  • Visible Kanban boards. The teams look at their Kanban boards during their daily stand ups and they are displayed on big screens in the office. (Kanban Core Practice 1: “Visualize”, Mike Burrows, Kanban from the Inside, Part I introduction)
  • Switch from TFS to Jira. By changing our lifecycle management platform at the same time, we had a clean break and a new workflow designed from scratch. However this was still based on our established flow. (Kanban Foundational Principle 1: “Start with what you do now”, Mike Burrows, Kanban from the Inside, Part I introduction)
  • Continued to use sprints for planning and releases initially. To smooth the transition from Scrum, we started with two-weekly sprints for planning and reviewing. Although we still have the two-weekly releases, the teams are naturally now working from the backlog and the flow continues.
  • “Hierarchy of business value” and release blockers. Backlog items are prioritised by business value, so the teams can just take the next item from the top. Key issues that must be fixed in a customer release are identified with a special priority and are picked up by the next free person.
Kanban board
A newly-minted Kanban board, as a team starts to make the transition away from Scrum.


The transition has gone well, but there are some challenges. We need to focus more on keeping Kanban board clear – finishing rather than starting items. (Kanban Core Practice 2: “Limit Work-in-Progress”, Mike Burrows, Kanban from the Inside, Part I introduction). This means that developers will often have to pick up testing activities as the Testing queue builds, which requires a change in thinking from “developer” to “team member”.

Kanban on monitor
As teams become more comfortable with Kanban, the boards are formalised and converted into dynamic, digital dashboards.

With emphasis on flow, all team members have the same responsibility to keep things moving (Kanban Foundational Principle 4: “Encourage acts of leadership at all levels in your organisation… “, Mike Burrows, Kanban from the Inside, Part I introduction). Everyone in the team needs to be encouraged to step up and contribute to the success of the team.

Planning a sprint to capacity and then seeing how many story points are delivered makes measuring a team’s velocity straightforward. However, now that the teams are working on items which can be of varying sizes, the velocity will not be reliable until we have been working this way for some months.

I have been involved in transitions of this kind before, but this has been particularly smooth. In six months, I’ll look back again and see how far we have progressed to our ultimate goals.

Comments 4

Hi Susan, I am a little curious how Kanban helped you with Speed of business delivery when Scrum could not. Some of the items like bugs and not delivering on the features seem to be a function of lack of code hygiene and planning than Scrum itself.

Join the community

Sign up for free to share your thoughts