How to Supercharge your Agile Board (Kanban Board)

Kanban boards, Agile boards Scrum boards - whatever you call them we're going deep on them I'm talking column naming process columns buffer colums Swim Lanes blocked items WIP limits card aging everything from the basics to some rather nifty tips and tricks Welcome back to the shed at the bottom of the garden where we are for the very first time attempting a fancy 2 camera setup. And no: what's coming is not a rant about physical boards versus Agile boards. Most of what I'm going to be talking about today can be done on both but I will be highlighting things that can only be done on a physical board and one or two things that can only be done on an electronic board That said what are we looking at here well we're looking at a Kanban board that's probably the most correct word for it name for it Agile board I think is probably become quite common Scrum board as as well often used by Scrum teams surprising that whatever you call it I would recommend it for any Agile team regardless of framework or methodology. Three columns - not three Swim Lanes by the way: I'll say more about Swim Lanes later. Three columns To Do Doing and Done. This is the only column where work gets done - you could call that an active column I call it a process column. I'm not even sure that's the right term if you know of if you know of the correct or better term please let me know in the comments The board of course is for tracking work the very first board I had any dealings with was was one very much like this it was using a whiteboard with drawn on columns and index cards to track individual backlog items across the board aided and a beted of course by a Blog of BluTak other brands available the second board I had dealings with was printed on a big sheet of paper with columns just wide enough for a single PostIt and this is how the board might look for a Scrum team if this was right at the beginning of the Sprint the items here are essentially the Sprint Backlog That's of course not the case for Kanban more on that in a moment when an item is picked up it's moved into this column to indicate that it's now being actively worked on and it's at that point and know earlier that this item should be assigned to a person as time goes on items get pulled in from to-do and eventually items may get all the way across to the done column and by the time if this is again if this is still the Scrum team by the time we get into the middle of the Sprint that the board looks pretty much as it would for a Kanban team Going back to the to-do column as I said Scrum teams have a Sprint they have Sprint planning they have a way of generating work for this column. In Kanban things are a little different in Kanban the the work pretty much drives everything and we can enable that with another line on this [Music] board this in Kanban is called called a trigger point. It's very much like a reorder point that supermarkets and such like will use to let them know that they're running short on a particular item and that they should go on and order more stock and that's exactly how it works on the board in this position there were three items still left in to do well nothing to do at the moment but when this item gets picked up and now these two items move move up above this trigger point that's the time to call a meeting and and typically it takes a while to get the meeting together to run the meeting to the result of which will be more items for the to-do column and the idea being is that if this is the state when the meeting is called there's enough work to carry on with if it takes say a day or perhaps ABS two days to get that meeting organized so maybe this one gets picked up in the meantime this one gets Al also gets picked up and then finally the result of that planning meeting would be some extra work that would hopefully fill up this column again trigger point In these days of continuous integration has been a long time since I packaged multiple items into a release but back in the old days when when I used a board like this this was a nice little trick to create a like to use an index card to represent a release and to use it to gather together items that would be part of that release making it easy for the person whose job it was to to handle the release to pick up this index card check that everything was okay with all of the items that were part of that release and package it up and send it on its way we've got our board and we're able to track work across it but the board can do a lot more for us than that and I've cleaned most of the work off the board just to make the point that if we can take items from to-do get them into doing and get them over to done if we can do that in the shor Test possible time well you can't really get any better than this that's what in Kanban is called single piece flow and it's kind of what we're always trying to get to in the real world though we often end up in a situation that's very different than that with a doing column that just gets longer and oops and longer and longer and it's easy to see how this can happen we are after all doing Agile we're solving difficult problems chances are from time to time we're going to get stucked out items are going to get blocked and what we what we tend to do is reach for another card that's why the doing column left unchecked can continue to grow and grow and that's a problem because we end up with a situation where things hang around a long time in the doing column the very opposite of the single piece flow that I described before and here's one thing that I can't easily represent on this physical board but some electronic boards can do do and that is to indicate the age of cards it was actually the reason I upgraded to a paid Trello subscription was to have this kind of visual aging where the cards kind of fade away over time and card age is actually a pretty powerful parameter we're going to get into work in progress limit in a second but you're going to essentially extrapolate all of Kanban from this idea of minimizing in the age of all of the work items powerful powerful stuff. Let's move on Red pen at the ready let's go ahead and impose a WIP limit and because I've got a physical board and my column is just one Post-it wide I can do this rather night nifty trick putting a horizontal line to indicate that work in progress limit WIP limit for short four cards being the maxim that is allowed for another electronic board it's more typical that the number is written at the top of the column somewhere and a breach of that whd limit reach of that WIP limit it's quite hard to say is typically indicated by turning the entire column red now if you're using an electronic board but it doesn't support work in progress limits I have a little bit of a hack for you let's say just to fit on my board that this is the work in progress limit just three items a of indicating that work in progress limit and remember I did say this was kind of hacky is to create a dummy card ideally change its color and it gets positioned at the bottom of the the list here the idea being that if another card is picked up it ends up here and it's visually obvious that the WIP limit has been breached now the problem of course is when this card is mov moved then these all Ripple up and it's a manual operation then to reposition this one in the fourth position in this column as for coming up with a number for that work in progress limit my rule of thumb is to take the number of people doing the doing and multiply it by somewhere between one and a half and two maybe start at twice the number of people and over time attempt to reduce that number down Remember the board I mentioned earlier the one printed on a big sheet of paper well the first thing I noticed about it was that it was made of paper the second thing I noticed about it is that it had many many columns many more than the three columns you see here before you so yeah let's talk about adding more columns into the mix so I've redrawn the board it's starts with To Do ends with done but in place of Doing I now have three active three process columns we'll talk about what they are in just a moment but the big question is do we need extra columns and how do we know if we need one two or three and the way to determine that is to figure out if and how often work changes hands so if work goes from too and is picked up by this guy and this guy takes it all the way to done then one column is enough if and if that's how all of the team operate everyone picks up their own ticket and sticks with it all the way to the end one column is enough the the board that we were just looking at before the doing column in the middle perfect however oops that person shouldn't have been I early assigned someone there shouldn't shouldn't be assigned at this point if however this person picks up the ticket assigns himself or herself to it and then passes on to someone else then it looks like we need two columns and I I'm sure you can see where this is going if this person then passes on to another person Bend three columns is the right number so let's fill in a possible set of three processes for this particular team I hope I'm not going to upset anyone by having Test as a as a separate process I know there's a little bit of a problem with with that in Agile I'm using it as an example possibly because it's actually quite common to find teams with a with a Test function if you have concerns about that I hope I will lay some of them in a second going to say that this process is Dev and the first one is Design three processes three columns going to move this one back here and put these guys at the top of their um processors actually let's let's give Dev a helping hand three quick points before we move on first of all what I've drawn here as a little bit unfair we'll be fixing the fairness factor in just a moment secondly I hope you got the message when I talked about handing work passing work it's almost like passing the bat on from one person to another across the board that I hope you can see is is very team specific in a company with multiple teams it's unlikely they're going to be having the same structure of work or workflow across all of their teams and yet what I see too often is companies that have standardized their Agile boards again probably using jir or similar giving everyone the same structure even though it probably doesn't match the team so keep a team my advice here would be to keep a team specific two team sitting right beside one another one might have three columns here one might be happy with just a single column should be team specific final thing to say and then we'll move on when naming these columns I've tried all kinds of naming strategies the one that works the best is to use the imperative voice the imperative because I do sound like something of a of a grammar nerd here (and I kind of am) the imperative is the is the thing that you use when you're giving instructions like Jump! Run! Stop! Go! that kind of word so Design it's like a command Develop! it's like a command. Test ! - like a command This works well in pretty much every situation I've come across and tends to be shorter terser easier to write on a board like this than options such as Design ing Developing Testing or even something like In Progress In Design In Dev In Test. Keep it imperative We have a board now that accurately reflects the way this team works it reflects its workflow: Design into Dev into Test. Now concern you may be having and it's certainly one that a colleague of mine had back in the day the first time we went for a multicolumn board like this and his concern was doesn't this drive a wedge between the individual functions between Dev and Test between Design and Dev and yeah I mean that kind of makes sense what I hope I'm going to show you that actually the opposite may be true that it might help the various parts of the team to work more closely together we'll get to that in a moment what is a valid concern is to do with working progress I hope you can see that even if we restricted every column to just one item they'd still be three times as work three times as much work potentially in progress than we had in our single column setup so yes we have paid a price in terms of work in progress when moving from a single process column to three process columns and we do it willingly because of some of the benefits that are crew as I hope again you will soon see and the first of those benefits come when we add back those work in progress limits going to go for here here here and here reflect them at the top for the electronic version let's go for two here four here and two here now an experiened team might be able to operate here with a minim of work in progress but any real world team that I've ever dealt with certainly that have been a part of will sooner or later get to a point where where everything is at its work in progress limits question for you looking at this board and the work in progress limits which of these cards can move well it's only these two here Dev is stuck it can neither move items into Test nor pick up new work from Design . Similarly Design can't move into Dev nor can it pick up more work from To Do so what's a poor developer to do? Well one thing they could do is nothing that's certainly better than magically introducing more work in progress into the system but what they really should do is walk over to Test and ask if they can help out that's the positive thing to do and that's the response to aren't we driving a wedge no we're not those work in progress limits have actually led to Dev moving across to ask Test if they can help out if anything this board and those work in progress limits have drawn different members of the team together powerful powerful stuff and just to see that things really do unblock. Once an item moves here then this one can move all of these move up we can pull in another item here if we're ready and Design also unblocked we can pull things in a quick word about card value in terms of value delivered to the customer none of these cards have delivered any none of them will until they make it to the done column and they get released that's when value is delivered having said that I think it's true to say that this card all other things being equal is potentially more important than all of the other cards here only because it's likely to be the first that gets entered on and then gets to deliver its value so as things go across the board it could be argued that things get more valuable and that's one reason that in Daily standup provided we're using the walk the wall process otherwise known as walk the board that's the reason why we start at the top it's one of the reasons why we start at the top right of the board in order to make sure that we talk about the most important items first so we started here move down this column over to Dev go all the way down this column into Design if we run out of time if we exceed that time box 15 minutes and we don't get to these tickets it's not the end of the world we covered the most important ones there's also a really practical reason that we start at the top right if I again load this board up put everything at its work in progress limit as we saw before these are the only cards that can move if we start at the top during our daily standup we find this one can move well we've opened things up if I started to move cards starting here things would have got messy very very quickly did I mention blocked items let's talk about them now several ways that we can indicate blocked items on a board the first way that I see a lot um which doesn't make me happy I don't think it's a very good method but I can see why it's simple and it kind of works and that is to create a dedicated column for blocked items either just before done or just after to do yeah it kind of works but there are better ways on a physical board and I wish I'd known this back in the day when I used a physical boards this is something that someone told me about much more recently is that if this card gets blocked pick it up put it down like that we now have a strong indication that this card is different so that's another way of doing it the electronic version of doing that is to tag the card in some way and I guess ideally oops reaching for another postage this is the this is the blocked item you get gets tagged ideally you change this color and again visual indication on the electronic board that this one is blocked one other way of doing this which is the first way that I used I don't like it as much as this I'll say that straight away have a row that was specifically for blocked items if this was the item that was blocked got moved into this row to indicate that it's blocked now there's a subtle but important difference between this approach moving it down here versus turning on it on its Edge or tagging it with a yeah with a tag and that is what it strongly applies about work in progress if I leave it here if I move it on a diagonal or tag it it's still taking up work in progress It's still not possible for Dev to pull in some new work it's part of that oh I think we we said it was four but yeah it looks smaller than that just at the moment so I don't have a big enough Bo I'm really sorry about that however if we move it into this dedicated Row for blocked it looks well it's more than strongly suggested doesn't it the dev now just has two items in progress we've not only moved it into this role but we've removed it from the work in progress for that process column and my question to you is which is correct or at least which is more correct let me know in those comments right back at the beginning which is quite a long time ago now I mentioned Swim Lanes I would argue that there are no Swim Lanes here in the same way I think as in a Swimming pool which I think is where the term comes from and before they put any ropes in I don't think we talk about there being just one Swim Lane it's like they put the rope in and now there's one or two Swim Lanes depending on how you look at it anyway let's add a Swim Lane to this board I'm going to start by squishing everything up and kind of creating some space for it so here is our Swim Lane probably doesn't need to run across done what that gives us is effectively another route across the board from to do into time through to Dev Test and done and there is a number of reasons that you might want to do this and several reasons why you wouldn't I've used it in the past when the team was trying to add more unit tests to the code base and we decided to track that separately from other work on the board the most common use for this is as a kind of an express route across the board for super urgent items I think this is sometimes called a silver bullet Swim Lane is that good for items in the silver ballet Swim Lane yes it is is it good for the work on this board as a whole no it isn't this could take us into a discussion about curing Theory and I don't really know enough about that but yeah the message here is use them sparingly if at all when I added the extra columns I said there's a little bit of unfairness hiding here indeed there is and it's time for me to address it if I look at Design Design can pull items in from to do that is good but what about when Design finishes work what does it do with it well the only move available to it is for it to push push its work into Dev now if you know anything about Kanban you know it's all about the pull and not the push this is really I've always thought this was really unfair that all of a sudden Deb's got another item another another item this contrib buting to its work in progress that it never asked for that's the unfairness we need to set things up that so the dev has the same rights and privileges as design Design is able to pull Dev should also be able to pull I guess a hack on a physical board like this would be maybe to put the card halfway across the two columns of course for an electronic board that's not going to work so let's do this properly we're going to have to add in a few more columns I've got a board to clean so I've introduced two new columns which I hope are going to sort out the fairness issue both of the columns I added are buffer columns let's just indicate that with a buffer column is a column where no work gets done this is where work sits waiting to be picked up by the next stage so let's see if we really have solved the fairness problem so item into Todo Design can pull from from that column that's fine that was always fine when Design is finished it can move it into this buffer column that's a change of state that's not a push Dev now has has been given the right the privilege the privilege the Design always has to pull work in when Dev is ready for it so that's a pull it happens when Dev wants it and not a moment before and again Dev when this item is complete it moves it into this buffer column where it waits until Test is ready to pull it in in its turn and again Test now has the same privileges as Design and now Dev to be able to pull when it is ready the being as this sticker says we want to be pulling no pushing final step. Test doesn't need its own buffer column because the done column that we've had right from the beginning serves the same purpose when it comes to WIP limits I guess I can add back the WIP limits that we had before if I can remember them I think we had two there four there and two here and I guess we could do the same for these new buffer columns I might add a one here and maybe two here but we can do better than that by using something called Shared WIP shared work in progress but to do that we need to figure out who owns these new columns who owns these buffer columns so is this column owned by Design or is it owned by Dev and the answer of that kind of comes down to well it's a question of control when Design has pulled in - as we said and that's fair and proper and when Design is finished it needs a place to put it and it moves it over here all of that all of those actions were in Design's control everything that we did here pulling it in moving across to buffer is in designs control and it owns therefore owns both of those columns if Dev owned this column well Design would have been messing with it and that's not what we want that wouldn't have be fair so the way the column split up by the way you always end up with an odd number when you set up a thing like this is that there's a to-do column and then it goes pair pair develop owns this buffer column and Test and I guess in a way done as a buffer column and it is owned by Test now establish a work in progress limit that is shared across these two I believe it was two before when we only had Design so let's make it three and here's where that flexibility comes in we could have three items here or two and one one and two or all three in that buffer column let's do a similar thing over here Dev was four before so maybe five or even six would work there and for the sake of completeness six items here 5 and one 4 and two three and three two and four one and five or all six in that buffer column Test we haven't really changed so we just leave that unaltered establishing the ownership also helps us name these columns the long hand would be Design and Design Done, Dev and Dev Done. One final wrinkle this kind of a conventional way of laying this out which removes repetition adds clarity and emphasizes the pairing of columns. And that's it everything I know and probably a few things I shouldn't about Agile Boards. Did I miss anything? Did I get anything wrong? Do you have any top tips? Share them please - you know where: them there comments below!