7 Steps to Build a Kanban Board for a Scrum Team’s Impediments


A Kanban board for impediments and actions

According to the Scrum Guide, “Daily Scrums … identify and remove impediments to development …“. They also advise that this is a service for the Development Team offered by the Scrum Master. Often an impediment backlog is used for this purpose. I’d advise the Scrum Master to use a Kanban board for handling the Development Team’s impediments.

Most of the Scrum teams I’ve seen over time use impediment backlogs. In the worst case that is an unordered list of impediment items, stored as an excel file on the Scrum Master’s computer. That’s not good for several reasons:

  • Lack of transparence: Only the Scrum Master has access to that list, and even to him that list is not visible all the time.
  • Lack of participation: The Development Team can’t participate in the almost secret list. No self-organisation is encouraged. The Scrum Master has to delegate items if he wants others to participate.
  • Lack of structure: An unordered list gives no direction on which item to work next.

With the last two Scrum Teams I worked with, we came to the following solution: an action board, which is in fact a Kanban board for actions. We did this in the following seven steps.


From Excel to flip chart

1. Transfer the list from excel to a flip chart.

Put each impediment item on one line on the flip chart. Put the flip chart in the Development Team’s room or attach the flip chart paper on a wall in that room. If you get rid of an impediment, cross out that line to signal that it’s done.

That’s better, because it’s visible and therefore transparent for everyone involved. During a Daily Scrum e.g. everyone is able to see which impediments are resolved and which ones have not been addressed yet.

Next challenge is that the flip chart will look odd after a while, because of all the crossed out lines. It might become harder to identify the impediments which are not done yet. You could write a new flip chart after a while, and transfer the open impediments, or use a second flip chart, but the problem of the big batch size remains.


From flip chart to board with stickies

2. Transfer the list from the flip chart to sticky notes and attach all stickies to one board.

Put each impediment item on one sticky note. You could use index cards as well. Put all stickies on one board. If you get rid of an impediment, crumple the sticky up and throw it away.

That’s better, because now you don’t have to rewrite half of the impediments all the time on new flip chart paper if you tidy up the impediment backlog.

Next challenge is that nobody knows who’s actually working on which sticky.


Use name tags

3. Use name tags on each sticky to identify who’s in charge.

Write the name or the initials of the one who’s in charge of a certain impediment on the impediment’s sticky note. You can also use paper clips to attach name tags (little pieces of paper with name or initials).

That’s better, because now everyone knows who can be asked about a certain impediment in the Daily Scrum. This is very useful for long lasting impediments such as “Get the special hardware device xyz”, where one has to call diverse departments over and over again before the impediment is removed. With name tags no one will forget who signed up for this task.

Next challenge is that if you find new impediments and put them on the board, you might not have the time to organize it, i.e. find someone who’s in charge for it. You’d want to wait until the next Daily Scrum. Also if you crumple up stickies which are done, you won’t have the ability to have an overview of what you’ve achieved, say once a week.


Create todo & done area

4. Divide the board in three areas, “Todo”, “Doing” and “Done”.

Draw two lines on the board, one in the upper third of the board, the other in the lower third of the board. If an impediment is discovered, add it to the todo area. If an impediment is done, move it over to the done area.

Thats better, because now registration of an impediment is separated from its organization. Everyone who finds a new impediment just puts it in the “Todo” area, and in the next Daily Scrum the Development Team can figure out who should sign up for it. Also in regular intervals, e.g. every friday, the whole Scrum Team can have a look at that “Done” area, have a short reflection about what they achieved in the last week, and then crumple every sticky in the “Done” area. Btw: Bonfires with done-stickies lift the spirits!

Next challenge is that this board design is so familiar…


Turn board by 90°

5. Turn the board 90° to the left, replace rows with columns, and say hello to your new Kanban board.

That’s better, because – well, now you have a name for it, and you can apply much more principles and science to it, e.g. Theory of Constraints http://de.wikipedia.org/wiki/Theory_of_Constraints. Also, you can use Kanban terminology, e.g. impediment items are now called tickets.

Next challenge is that it’s not visible when you have to work on a blocked ticket. The nature of most impediments is that you wait for them more than you work on them. Ordering hardware, arranging meetings, negotiating conditions, all of those are often tasks one has to do to solve an impediment. So you don’t have to deal with every impediment every day in the Daily Scrum.


Write due dates on board

6. Use smaller stickies with due dates to indicate blockers.

Write down the due date on a smaller sticky. Due date is the date of the next action required for a certain ticket. Put that due date sticky right on top of the blocked ticket. You only have to do this for the “Doing” column. Order the “Doing” column according to the due date in ascending order from tickets without a due date to tickets with the highest due date.

That’s better, because now in the Daily Scrum you only have to focus on expired tickets, i.e. tickets either without due dates (in columns “Todo” and “Doing”) or with due dates that are less than or equal today’s date (in column “Doing”).

An example: Today is 01.08.2011. To resolve an impediment you ordered hardware, and the delivery time is 2 days. Now block that ticket with a due date sticky note. The due date is 03.08.2011 (+ 2 days). You don’t talk about that ticket on the next day’s Daily Scrum (because 03.08.2011 is not less than or equal than today’s date, which is 02.08.2011). But you adress the ticket on the day after tomorrow’s Daily Scrum (because 03.08.2011 is equal than today’s date, which is 03.08.2011 then). And maybe you won’t be able to do your day after tomorrow’s Daily Scrum (because that could be a national holiday), and you would only be able to do the next Daily Scrum on the day after that (which would be the 04.08.2011). Then you’d also address the ticket, because 03.08.2011 is less than 04.08.2011.

Next challenge is that you now probably have two tools for the same two things: a Kanban board for impediments, and something else for your actions, e.g. from your retrospectives.


Manage impediments and actions on same board

7. Integrate actions into your impediment Kanban board.

Put all your actions from retrospectives or other sources onto the impediments Kanban board. Rename your board and call it action board.

That’s better, because now you have all activities in one place, next to your stories on your storyboard. Because actions and impediments are so similar (you do actions to solve impediments, too), you can handle and track them with one tool. If you want to distinguish them (e.g. to measure different average lead times), use stickies with different colors.

That’s it. You turned your impediment backlog into an action board.

Outlook: Now that you have an action board which is in fact a Kanban board, you can apply all kinds of Lean methods and principles, e.g. introduce WIP limits or measure lead time.

P.S.: I think this is a great example of the use of Kanban and Scrum within one system. Would you agree?

This entry was posted in General and tagged , , , . Bookmark the permalink.

About Bernd Schiffer

Bernd Schiffer is consultant, trainer and coach for Agile Software Development in Melbourne, Australia. Learn more about him on his personal homepage, have a look at his company Bold Mover, or contact him on Twitter, Google+, Facebook, XING or LinkedIn.

26 Responses to 7 Steps to Build a Kanban Board for a Scrum Team’s Impediments

  1. Pingback: Handling Impediments with the Task Board « Stefan Roock

  2. Pingback: Bernd Schiffer: 7 Steps to Build a Kanban Board for a Scrum Team’s Impediments « Agile Links

  3. Hello Bernd,

    Stefan Roock has recently referenced your post.

    It’s great!

    I have translated it into french :
    http://agilarium.wikispaces.com/7+%C3%A9tapes+afin+de+construire+un+tableau+Kanban+pour+les+obstacles+de+l%27%C3%A9quipe+Scrum

    Thank you,
    Fabrice

  4. Vin D'Amico says:

    Fantastic idea! We use scrum and kanban boards to track work. So, why not use them to track impediments? We could apply the same concept to the results of our retrospective meetings. Making these items visible and trackable is a great way to make them happen!

  5. Jeroen says:

    How can kanban be used as a better alternative to project management using Gantt?

    I was wondering what your take is on the following. How can kanban best be used in a (non-IT) New Product Development process, as a better and lean alternative to traditional Project Planning using Gantt?

    Thank you in advance for your reply,

    Regards,

    Jeroen

    • Jeroen, it depends on your context. Kanban can be an alternative to Gantt, but if it’s better for you depends upon your environment. The strength of Kanban (like most of the Agile methods) is to operate in complex environments, whereas the traditional project planning with Gantt has its strength in complicated environments (afaik, and I’m no expert in Gantt) – see the Cynefin framework for better understanding of the difference of complex and complicated. If your environment is definitely complicated, then you might not benefit from Kanban (or other Agile methods). If it’s complex, you should seriously consider to experiment with Kanban (or other Agile methods) within your company.

      Hope that helps. Please contact me via email, if you need more information. Bernd

  6. Neil Killick says:

    I think it’s important to understand that Kanban is not in itself an Agile method. Kanban can be applied to any situation where there is a flow of information, and can certainly be used without any kind of Agile adoption or process change of any kind.

    Kanban makes bottlenecks and progress visible, which are “agile” principles, but only when Kanban is applied to building software using a framework based on delivering early and often (such as Scrum) does it start to complement (rather than “be”) an Agile delivery method.

    So in answer to your question, @Jeroen, Kanban by itself is not an alternative to tracking the development lifecycle of a product. Scrum provides a framework for concept through to delivery which perfectly suits the development of a new product. In fact it’s what Scrum was designed for.

    Once you get going with Scrum you can certainly begin to apply Kanban and Lean principles, which tie in very neatly with Scrum principles such as “stop starting, start finishing”, “swarming” and “sustainable pace”. But don’t try and introduce too many concepts too early. Scrum provides a framework for continuous improvement, where the team inspects and adapts its process every Sprint, so there is no need to try and make everything perfect at the start.

    As for Gantt, there are issues with using Gantt charts in modern software development which are too numerous to go into here. Scrum applied properly with an empowered Product Owner creating artefacts such as product vision, concepts and release plans, and the team working in timeboxed Sprints, is an excellent alternative to a traditional project-based approach to building a product.

  7. Pingback: A World without Burndowns: the Unified Taskboard « Minds

  8. James says:

    I graduated from paper almost 15 years ago, and I am not looking back to something that would be horribly manageable and degreade productivity. Using Outlook tasks is much better than using index cards. Like I said, I moved forward about 15 years ago, and I am not looking back.

    • James, for me it’s not a matter of graduating from one technique to another (i.e. paper to digital). If Outlook tasks work better in your situation than index cards, then congrats on finding a tool you can work with. However, that’s your experience, and I wouldn’t recommend to assume from this that this is the better tool in all environments. I’ve experienced many environments where the approach described above works just brilliantly – and yet I wouldn’t dare to say that this approach is always better than another approach (i.e. in distributed teams). It depends upon the environment and the situation at hand.

      You mentioned that you “moved forward about 15 years ago”. Again, for me it’s not a matter of time. Kanban itself is over 60 years old, and it turns out that for many practitioners it’s still up-to-date and very worth to work with.

      After all that said, have you ever tried working with index cards, or even a Kanban board? If so, I’d be curious appreciate it to hear more about why it “would be horribly manageable and degreade productivity”.

      • Clarence U says:

        My experience with “old school” technology such as using boards and stickies has been refreshing. They are transparent (as long as they are not hidden behind a potted plant – ha ha) as they are “in your face”, not hidden in computers. They also encourage great team collaboration through the stand up meetings at the location of the boards, and enable celebration of successes. It has brought a few of us out of our comfort zones through greater transparency and more action oriented conversations- but this is a good thing as it shows that we are doing something different and developing ourselves :)

  9. Pingback: Maak je actielijst visueel voor echt resultaat -

  10. Eddie Uren says:

    Well written, and perfect for what I needed in moving from perceived control / order to a process that would actually work and bring benefits. Thank you!

  11. Gary Moore says:

    Bernd, I’m a big fan of the Action Board that you describe here. I wanted to let you know that I have used this method with Scrum Teams that I’ve worked with and I mention it as a best practice in training sessions that I’ve done. I also presented the idea to the Agile San Diego community last night and it was very well received. A belated thank you for offering this up to the Agile community.

  12. Paul Klipp says:

    Can I ask why impediments should be separated from the work being impeded? I presume that an impediment is something preventing some value-adding task from being done (at all, or as well as it could be).

    On my boards, such things are attached as blockers (pink Post-Its) directly to the task that is being blocked or when working with remote teams, as a “blocker” in Kanbanery.com, which behaves the same way, illustrating the link between the work the manager has to do and the work that engineering is being prevented from completing.

    In that way, it’s easy to see at a glance both the Scrum Master’s responsibilities and the implications of not removing the impediments, making it easier to prioritize the work. It also means one task board for everyone.

    • In the case of your presumption (an impediment is something preventing a task from being done), I’d also go with a blocker note (or just get rid of that impediment right away). If we’re in a Scrum context with sprints as timeboxes, sometimes an impediment can’t be resolved within the remaining sprint. If it’s still worth resolving that impediment, we can’t use a blocker note, since it wouldn’t survive the reset of the sprint backlog at the end of the sprint. So we need a place to remind us of the impediment and make it visible as long as we try to get rid of it. Hence the idea of the action board. Same thing for retrospective actions if they take longer than the length of a sprint. Besides, retrospective actions are very often not tied to a specific task or product backlog item, so that they can’t be turned into a blocker or, well, “action” note.

  13. Pingback: Het fysieke Kanban of Scrum bord | Agile Aware

  14. Pingback: Impediments | Agile Lucero

  15. Pingback: Kanban Principles |

  16. Pingback: Scrum Excel |

  17. Pingback: Impediments - You ain't got no stinkin' impediments you say...

Leave a Reply

Your email address will not be published. Required fields are marked *