Using both Kanban and Scrum

Yes you can certainly use Scrum with Kanban.  In fact, the PSK1 certificate is based upon this process. 

The following page has links to the Scrum with Kanban guide as well as suggested reading for the exam: 

https://www.scrum.org/professional-scrum-with-kanban-certification

The reason for this is that by using Kanban without Sprints, we miss the sense of urgency: there is not as much pressure to actually finish work. 

Where is the pull for finished work actually coming from? Who wants value to be released early and often, and to inspect and adapt based on empirical observation?

Although a Kanban strategy can indeed be implemented using Scrum, the use of Sprints to establish a false sense of urgency would not prove rewarding for long. A quick sugar high is all you are likely to get.

It's definitely possible to use Kanban with Scrum. Scrum is a light enough framework, so the application of Kanban adds some additional metrics and ways to use those metrics to support the Scrum events. The Kanban Guide for Scrum Teams is a good starting point, and Daniel Vacanti's books Actionable Agile Metrics for Predictability and When Will It Be Done add some good data.

Using a Kanban board to visualize the workflow (and perhaps limit work in progress) is only one piece of what Kanban is. Kanban involves measuring the amount of work in progress, throughput, work item aging, and cycle time to provide insight into the effectiveness of the workflow. These metrics can support the team as they meet the objectives of Sprint Planning, the Daily Scrum, and the Sprint Retrospective.

The idea that you're using Sprints to create a "sense of urgency" seems wrong. That's not the intention of the Sprint cadence. The timeboxed Sprint is one way to constrain a team to limit work in progress, although less strict than applying the Kanban tools. However, more importantly, it adds a sense of predictability. There is a minimum cadence of delivery of working product, a regular time for the team to synchronize with key stakeholders, and a guaranteed timebox for retrospection and process improvement. It's not about putting urgency or pressure on achieving work within a deadline, but to plan, reflect, and adapt on a regular schedule.

We have some product backlog items that represent work that I believe would be considered simple work ... i.e., it would fall into the Simple zone of the Stacy Diagram.  High level, the work involves conversion of existing digital request forms to work in a new digital workplace tool we are using.  Hence, we know what to convert and how to execute the conversion work. 

This work is one part of an overarching product roadmap.  The rest of the work on the product roadmap is being done through the normal Scrum framework.

I’ve talked about this work with the Product Owner and he feels that it might be good to track this conversion work via Kanban.  I have done a little bit of research here on Scrum.org as well as read over the Kanban Guide for Scrum Teams.  Where I get a little confused the part where, in Scrum, during our Sprint Planning sessions, we would estimate work that could be pulled into the next spring.  Given that this work would not live in sprint, but instead, be tracked on a KanBan board, does anyone have any guidance/pointers on if/how this can (or even should) be done?



Apologies in advance.  I am a new Scrum Master and only about a month into the role so thanks in advance for your patience.

he feels that it might be good to track this conversion work via Kanban

What would be good to track about that work? Would there be a throughput of immediately usable converted items?

I have some thoughts and questions. 

If this "simple work" is part of the same product as the other work you are doing in Scrum, it should still be made transparent in the same product Backlog, even if there are multiple teams working on the same product. 

I'm not sure what you mean by "track this conversion work"? If the intent is to understand progress and when it gets completed, could you use either a Sprint Goal or Product Goal (if it takes more than a Sprint) and make these goals measurable? 

One other idea. Your Product Backlog is your plan in Scrum. Perhaps the Product Owner might order this "simple work" cohesively. By grouping this work it could be made transparent what is in progress and what is remaining, and might be a good conversation in the Sprint Review

in Scrum, during our Sprint Planning sessions, we would estimate work that could be pulled into the next spring.  

One minor note: Sprint Planning kicks off the current Sprint, we're not doing workin in Sprint Planning for future Sprints. You could use Product Backlog refinement for understanding future Sprint effort.

Scrum on

Ian / Chris.  Thanks for the feedback.  I had a chat with the Product Owner and I am much, much clearer.  So, the short synopsis is, I was overthinking this.  ( - :  Just to close the loop with you gents since you were kind enough to reply back:

Our product goal is to create a one-stop request system using a new technology that is going to be implemented within our organization.  We currently have a legacy system that users utilize to request various services within the Enterprise.  Those legacy requests, however, will come over to the new system and consequently, require some conversion work to make them useable in the new system/infrastructure.  This work is viewed as tech debt that has existed long before the formation of our Scrum team and its product goal.  The amount work required to convert the legacy requests varies and is an ongoing effort.  So, in our respective Sprint Planning sessions, we will not pull any of the PBIs that represent conversion work ( the tech debt work ) into the respective sprint backlogs.  Instead, we will focus on the non-tech debt work but use the KanBan concept of "pull" to allow the developers to pull in conversion card if/when they have "white" space in the sprint.  Of course, the developers will tag the PBI in AzDO with the correct sprint # so we can then go back and see what was completed for metrics purposes.  I think where I got confused is I was thinking that the PO wanted to actually maintain a literal / separate KanBan board for this work.

Hopefully that makes sense.  If this sounds like something those of you who are experts / more experienced think is concerning, I welcome your feedback.