 Hi, welcome to this tech talk titled Kanban and Alternative to Scrum, question mark. And I'm Kevin Smith and I'll be giving this talk. So who am I? As I said, I'm Kevin Smith. I'm an Agile Coach here at the Wikimedia Foundation on email and other places on KSmith and IRC at Meeple27. My background is as a software developer mostly in C++ and Java, but I've been interested in Agile processes for a long time. So a little history about Kanban. It was developed by Toyota, the car company, started in the 1940s, and they did it to improve auto manufacturing efficiency, but later a lot of the ideas were applied to other processes including software development and information technology work. Kanban is a very open-ended framework as I'll sort of get into some more details of that. When I first started reading about it, it was hard for me to understand what it even was. The descriptions were so vague and hand-wavy that I got. It's like, well, what do you do? What does it look like on a day-to-day basis? It was hard to get that information until I found the right sources. There's a lot of information out there, which leads me into the land of confusion. So when you're talking about Kanban with anyone, it's important to make sure that you're talking about the same thing, because Kanban means different things to different people. So there are a number of different possible definitions of Kanban. It's a system for lean manufacturing, as I mentioned, that Toyota developed. But technically the word Kanban actually means the card or the piece of paper that's used as the signal in the Kanban process. Kanban is often used as a meta-process for improving any process. So it's not really a process, it's a process about a process. And then a lot of people consider it to be an actual software development process. And I'll pause here and mention that if you have questions, feel free to just drop in maybe at the end of the slide or when you feel like you have a question. So on that last slide, I had some question marks after Kanban being a process. And that's because one of the pioneers of the Kanban method says Kanban is not a software development life-cycle or project management methodology. It's not a way of making software or running projects that make software. Which sounds like it's a contradiction to what a lot of people view Kanban as. Quick question, Kevin. Regarding the previous slide, what's the recommended source for further reading? I will have references at the end in the slide which will be published. Okay, great. So for this talk, Kanban is a very light framework. So it's not a process, it doesn't tell you exactly what to do, but it's a way of thinking that can let you, very light, upon which a team can build. So the team actually has to take this and turn it into their own process. A lean and agile software development process. Lean is closely related to agile for the purposes of this talk. We sort of consider them the same thing. They have similar roots and similar ideas. So Kanban, I mentioned it's a very light framework. So you may have heard of the waterfall method. Modern approach that's a waterfall-y thing is called B-Model. Apparently it's used in some military applications and things like that. And those kinds of process, waterfall itself can be lighter, can be heavy, whatever, but those types of processes tend to be very heavyweight, very prescriptive. So this is just kind of, you know, it tells you how to gather requirements, when to gather requirements, how to document your requirements, how to cross-reference your requirements. Then you get into your design and your analysis, and it just, at each step of the way, it tends to tell you, you will do it this way, you must do this, you must do this, you must do this. So the agile software development movement was sort of in response to that. And so Extreme Programming was one of the earlier agile methodologies. And it has certain things that you have to do. If you're doing Extreme Programming, you are pair programming all the time. You are having the planning meetings. Your product manager, essentially, your customer is on-site with the team. And so there are these fairly strict rules that you have to be doing these things to be doing Extreme Programming. So it's not as prescriptive as the V-Model, but there's some things you have to do. Scrum is sort of the next step lighter, where with Scrum you'll have your product owner, your Scrum master, your team, you'll have fixed iterations of typically two or three weeks, not more than a month, and you'll have daily stand-ups, and you'll have... And that's about it. So it's very light still. There's not much that you have to be doing to say that you're doing Scrum. Combine is even lighter. Basically, it's this sort of empty platform upon which you can decide to build your own process. It doesn't say that you'll have daily meetings. It doesn't say that you'll have a product owner. It doesn't say that you'll estimate your tasks. That's why I consider it to be very light. So to talk about Kanban, just to get a little more specific, there are a lot of flavors of Kanban and takes on Kanban, and the one that I've sort of zeroed in on is called Open Kanban. There's a link to it here. And it's just a specific way of talking about Kanban. It's aimed at software development projects or other IT projects, so that's handy for what we do here. It's also released under the Creative Commons, which is nice because you can redistribute it, interpret it, adjust it to other works for you. It's still at a more conceptual level, not a practical level, so it won't tell you to do care programming or not, or have a product manager or not, but at least it's a, as I'll show you, they have these practices. So the practices are not, again, at that detailed level, but these are the things that you do if you're doing Open Kanban. So first is to visualize the workflow. So if you're doing work, it's moving from person to person, station to station, process to process, whatever. They want you to visualize that somehow. How you do that is up to you. Team approach with leadership. This one is sort of the outlier bullet point. I don't know why they included this as one of the four of Open Kanban. It's not a typical traditional Kanban, but yeah, you'll have a team and they'll have some leadership. Reduce batch size. And also they don't mention it in Open Kanban, but it's closely related to limiting work in progress, WIP. And so I'll talk quite a bit more about that. And then finally, continual improvement and learning is always a very big part of Kanban. The idea is that on an hourly basis, daily basis, weekly basis, monthly basis, you're continually looking at how you're doing, evaluating, looking for ways to improve and learn to do better. So first bullet point was visualizing the workflow. And the simplest way to do this is on a work board. And typical Kanban work board looks a lot like a scrum work board. It looks a lot like the work boards that we have in fabricator here. You have columns for the different phases that a task is going to go through. So here you can see that support IE9 is a task that we hope to do sometime soon. Somebody is currently working on adding a sort button that's in progress. A couple of bug and a feature have been coded, but they're in review right now. And then a couple of items have already been done and at least released to the next staff, whatever that gets. So there are other ways of visualizing your workflow, and one of them is a cumulative flow diagram. And there's an example here. It's kind of like a burn-down chart or a burn-ups chart on steroids if you're familiar with those. And so essentially time is going across left to right and the number of items or the number of story points or whatever you measure in is going on the vertical axis. And so you can see that on day one, there's a lot of stuff in the backlog, the light blue, and nothing's been done yet. And then as time goes on, things go into development, which is the green, and then they move into tests, which is orange, and then they move into production, which is the dark blue. So on any given day, you can see the distance between the dark blue line and the top of the light blue is your work in progress. Those are the things that are either in your backlog or they're in your development or they're being tested. Going the other way, you can see the yellow arrow on the ten were basically something that entered the system on day four, exited on day ten. So that means that there's six days from when it went into the backlog until it came out into production. And that's not to say that one task exactly took six days to move there because it could have been that one task got solved and some other tasks bypassed it. But on average, that's the lead time from when something enters the system until when it exits the system. Yes. Is this essentially what some people call a burnout chart? It is, right, a burnout chart is typically, if you took out the dark blue, orange, sorry, no, if you took off the light blue, green, and orange and just looked at what was actually in production, that would be a burnout chart. And this just adds additional information to it. There's also cycle time and lead time are closely related. Essentially cycle time would be from where the, where it transitions from light blue into green from that point over to the dark blue. And essentially where lead time is from when it enters the backlog until it gets delivered, cycle time is from when it starts to be worked on until it gets delivered. So they're somewhat interchangeable depending on how precise you need to be about one versus the other. Kevin? Yes. Is there no sprints in this? I know it sort of never goes down, but I mean, do you have sprints or does it just keep going more and more? Right, so the short answer is you do not necessarily have sprints. This particular cumulative flow diagram is only two weeks so it could be within a sprint time frame. But combat does not require sprints. And this chart could be graphed over one week or it could be graphed over a whole year. So the next main point of the combat practices was reduced batch size. So what's a batch size? A batch size is the quantity of work that passes from one stage to the next. So if we look at those work boards, a task as it moves across the board, that's a batch. So it worked on feature X and then it went into testing and then it went into deployment. That was a batch moving across the system. At a different level, in Scrum where you have these fixed iterations, you work on something, you test it, you get it all ready, and then at the end of the sprint, you release it, you deploy it, whatever. So at that level, everything that you've done in those, let's say, two weeks because as far as the customer is concerned, the person is actually using the website at the end, anything that you did on days one, two, three, four, five, they don't see it. They don't see it until it actually gets released. And so at that level, Scrum typically has a two-week or one-week or three-week batch size. Small batches are nice for a number of reasons. They're more predictable. It's easier to estimate small amounts of work. They tighten feedback loops because the smaller amount of work you deliver to the customer, the faster they can tell you what they like about it or don't like about it. They generally improve agility. If you have five small tasks, then the product owner can rearrange those in whatever way makes sense, whereas if they're all considered part one big story, then you use that control. So there are a number of nice reasons to have smaller batches. So flip side of that is to minimize the work in progress at the IP. And so if you look at that, work in progress is everything that you started but you haven't finished. And by reducing that, you get a number of benefits as well. So one thing is you improve your focus. If you're doing six things at once, you're not sure what you're doing and you have to remember them all. If you have one thing you're doing, you know what you're doing, you're focused on it. Right along with that, that minimizes context switching. So if you're working on three things at once and each day you're working on a different one and then you go back and work on the first one again, you have to relearn kind of what you forgot. So if you could be doing just one thing at a time, that reduces early makes context switching. It can also avoid creating output that's never used. And a great example of this is the code review question that's sort of been popping up on mailing list recently is we have a lot of these patches that haven't been reviewed for weeks or months and they're just sitting out there essentially rotting. So there may be a number of those that it turns out that the code has moved so far forward since that patch was done that that patch just isn't mergeable or doesn't even make sense. So that means that that patch at that point is total waste if somebody did the work and it was for nothing. And so by minimizing that work, all of those patches that are waiting to be reviewed are work in progress and by reducing that, that reduces the chances of wasting effort for that reason. Minimize the work in progress improves flow. It delivers value earlier. So if you're juggling three things and you get all three of them done before you hand them to the user, maybe you finished one and you got the other two 80% done before the customer saw anything, that's going to take a while. Whereas if you can start one thing and finish it over, then they get their values earlier possible. And so there's a con bond saying stop starting and start finishing. So it's typical in con bond to enforce whip limits and the way this can be done and this is supported in Fabricator is you can actually establish whip limits for each of your columns in your work board. So in this particular project they happen to say that they can have up to five items in backlog, up to three in progress, up to two in review. So if you look at in progress you've got task B there which is already the coding is done but there's no room for it in the needs review column because the needs review column is full of its whip limit is reached. There's two items there. So nothing can get pulled in from the in progress column until each of tasks C or task F gets reviewed and shifted to done. You'll notice that also in progress has only two items in it right now and so there is room to pull a task in front of the backlog. So at this point a developer or a product owner, somebody would pull probably task G into in progress and somebody could start working on that. Kevin, two questions. Well, firstly a comment. The sprint extension in Fabricator I believe has a, you can limit the number of stuff in the column. I don't know when to turn that on. Is that when to turn that on? Yeah, there's just things that use it and it doesn't actually enforce a hard limit but it does flag that you're over the limit. It shows you you're violating a little too much. Yeah. And the other thing is, so I don't understand you know, if you limit the number you can't, if you went the backlog to five what do you do with your 400 tasks? Are they in a backlog of the backlog? Right, that would be the typical way, this would be the backlog of stuff that we're working on it's shovel ready it's identifying we know it's high priority and we're going to be working on it. The list of the product backlog, so this is the equivalent of a sprint backlog. Product backlog which has the 500 items which are in various states of definition would probably be stored somewhere else. They could be stored in another column here but this team hasn't chosen to do that. We keep ours in another board and we find it less stressful because we don't see all the things that we haven't done. So what do you still call it? So you have a sprint backlog, do you call it backlog in that thing? It's kind of confusing. Our board is called backlog and then we have a column with slate next up which is the equivalent of the backlog column here. Right, so the backlog column here could be called to-do, it could be called ready. Right, I was looking at, so it's kind of like a to-do thing. So whatever terminology makes sense for that. Alright, so this is kind of to show how batch size and width work together. So the goal is to deliver completed work to each following stage as often as possible and typically you do that by reducing batch size and by minimizing your width. So at the far left we have these three tasks that need to be done, each one, let's say each one is a week long and you've got three developers and each one is going to take on one of those tasks. So as soon as the customer is going to see anything is about a week from now, which is not great, that's a fairly long time. Let's say it's a month, whatever scale you want, it's a long time. So in the second column this team decided to reduce their width and so they said we will not have more than five days worth of work to do at a time in the progress column and so that would end up in this case forcing all three developers to work on the same task. But it's still a one week task. There's still nothing that you're going to be able to hand to the testers or users or whoever in a day or two. Probably this is very abstract in this case you probably wouldn't actually put three developers on one single task because they'd be stepping up over each other. You could certainly put two on a task as a pairing program in your pairing exercise and in fact a priority treatment bit of work. So gloss over that and say just conceptually you're applying these people to this large batch. So the next column is now we've said we have an explicitly limited width but we've broken things into small batches. So now each of those large tasks has been split into two or three smaller ones and each developer can work on the big task. But in this case the top developer is kind of bouncing back and forth between these two parts and the second developer is bouncing both back and forth between those two parts and the bottom developer is bouncing. So you still have context switching and you still have the users, those tasks are not going to get delivered as quickly as possible to the next stage. So the final column is combining both of these where the tasks have been broken up into these small batches and we've made an effort to reduce the work in progress and so each developer is focused on just one piece at a time and you can see that there's that little sliver, maybe it's a day of work and the tester is going to have something to look at and then after another day the tester is going to have some more to look at and so it starts to create this flow of work through the system. So Kanban really is about continuous flow to answer your question from earlier. Kanban does not require fixed length iterations and so if you think of so Scrum has fixed iterations typically a couple of weeks at the start of it you decide how much work exactly what work you're planning to do during that time it's all estimated, you're pretty confident you can get it done you work during the sprint you get it done and then you deliver it. So it's sort of like you're going to faucet filling a bucket and then pouring the bucket onto the fire or whatever you're doing Kanban is much more like a hose stuff comes in and stuff goes out and it's just this continual motion of work. So Kanban does not require fixed length iterations which as a side effect of that tasks don't have to be estimated you're no longer working towards you no longer have to figure out what's going to fit in your timebox iteration so work shows up and you do your work work shows up and you do your work there's no benefits to doing estimation but it's not required by Kanban developers tend to like that because developers tend to be often unhappy giving estimates and being stuck with those estimates later. Stories can be added over a day and time so in scrum once you have that sprint defined technically nothing should be added to the sprint nothing should be removed from the sprint the idea is you can always wait a couple of weeks and however important was don't worry about it it will be in the next experiment a couple of weeks. With Kanban in that backlog column on the work board that we saw whoever is doing the prioritization has the flexibility and freedom to be able to add stories at any time as long as they haven't actually as long as the work hasn't started on them yet they can change their minds up to the last minute and so product owners tend to like that flexibility. The product can be released at any time a lot of companies now are actually moving towards continuous deployment so we could get to the point where product owner would say yep this is great they push a button at four o'clock on a Tuesday and it goes live to the site and then at eight o'clock the next morning somebody checked in some really cool stuff later that afternoon let's release that again and you can even get to the point where as soon as as soon as the code gets merged it automatically got pushed out to the site obviously for that to work you'd have to have awesome automated testing and other things in place it's kind of a a dream in a sense but there are companies that are actually doing it so it is possible and Kanban that fits well with Kanban with this idea that the work is just continually flowing through the system and anything that's stopping it is kind of getting in the way and maybe you need to but maybe you don't so a drawback with this continuous flow and tasks not being estimated is it can be harder to predict when a large specific feature set will get done it's kind of a problem in any software development to try to predict up front hey we have this amount of work to do when it's going to be finished but stream programming and Scrum have this concept of velocity that's pretty well cooked into the system and you have to be doing estimates so you can build up these reasonable predictions or as good as possible predictions of when this amount of scope will get done it's a little harder in Kanban you can get pretty close to that though if you're doing estimates and you're measuring you're using those continuous flow diagrams or similar tools you can actually measure essentially how fast your estimated work is moving through the system and therefore in the future how fast your estimated work is likely to move through the system but it's definitely less developed than Scrum in that sense sorry there's a couple of things there firstly you would have to like a big complicated feature you divide into a bunch of little pieces and then you know presumably somebody's moving the right little pieces onto the back log but you'd have to so the first thing is deploying them you'd have to have them under feature flags or something so that you'd be able to see oh this tiny little piece of the complete is working but you know obviously users can't see that because you've only done one piece but then how do you know how do you keep track of well before you can actually have the new search you've got to have all of these nine pieces done you've got to have some higher level pre-tracting all the elements you need otherwise you might wind up having seven small pieces of your big rewrite but not the remaining two right which is true in Scrum or anything that has to be managed and so that as far as the continual deploy that would be more of an issue you'd have to be careful there that everything that you do doesn't make the site any worse it may not make it any better because the feature is hidden or it's half there but as long as it doesn't make it work it's okay but yes that would be the responsibility of the product owner to do the sequencing and the actual decision to release based on what makes sense yeah so there are a couple terms Scrumbut so Scrumbut is when a team says well we're doing Scrum but so examples of this would be that they're doing most of the Scrum practices but they don't actually commit to what they're going to get done during a Scrum they do their estimations, they do their when they lay out the Scrum plan but they make it, they don't make it it's not really a big deal or maybe they don't have the daily Scrum meetings that Scrum says that you will have very few teams really are 100% pure Scrum I don't know I have no idea what a percentage is but it's so easy to deviate well ok, we don't need to do a retrospective every single Scrum or we're only going to do the spirit review or maybe the whole team is not cross functional or the whole team isn't on the Scrum plan there are a lot of reasons that it may make sense for that team not to do 100% pure Scrum so Scrumbut is actually pretty common and it's not necessarily a bad thing but just be aware that if you're not doing Scrum blame Scrum if it's not working Scrumbond is a mix of Scrum and Conbond it's a pretty vague term people cost ground it has some meanings you've taken some of the aspects of Scrum maybe you have a product owner and maybe you have daily meetings but then it's maybe you don't have fixed length iterations but maybe you do people could say Scrumbond can be applied to something that's really very much like Scrum a little bit of Conbond or very much like Conbond with a little bit of Scrum so be careful if you use that word but again you may not meaning what the other person thinks so when to consider Conbond it's really ideal when the upcoming work is unpredictable so if it's highly event driven help desk tickets coming in you don't know on Monday whether you're going to get 3 customer problems or 30 customer problems or 1 minute answer or a 5 day research project so under those circumstances obviously coming up with a Scrum plan that covers 2 weeks is very challenging and so event driven teams might favor Conbond another example is research tasks with significant true unknowns trying to qualify as many significant true real full unknowns everything in software development is unknown you're always inventing something with a research task you might actually be presented with a problem that you literally it might end up not being solvable and you might not know that for a month or you might have to invent something that you might have the right insight and it might be done in 2 hours and if you don't get that insight then maybe it'll take you 2 weeks so it's at that level that again Conbond starts to make a lot of sense because of the unpredictability other places it can work well teams that are very mature if they're hitting limitations of Scrum they've been doing Scrum for a while it's been working but those 2 week iterations or the 1 week iteration whatever they've chosen is limiting them in some way or some other structural piece of Scrum isn't making sense for that team then they could consciously make that decision to switch teams that are unhappy with more restrictive processes for whatever reason so for instance teams might have been trying Scrum for 6 months and they've been doing these estimation and Scrum commitments but every single Sprint they only got half of what they promised done and that can be very demoralizing so rather than perhaps solve the underlying problems that might make Scrum work in that place the team might just choose to go with a Conbond method that avoids the pain and teams that are just extremely resistant to any form of process so a new team spinning up and they've heard bad things about Adriel they've heard bad things about Scrum whatever Conbond is is so lightweight that you can just kind of say let's start with this and we can always improve and adapt and see what works as we go and then finally teams that are willing to extensively adapt Conbond to their needs and so if you may not be a mature team you may be fine with a restricted process but your team sees that Conbond would really work if you do all the steps necessary to make it work but it does take an investment so to summarize the answer to the question of the title of the talk yes the Conbond based process can be an alternative to Scrum however the structure of this one is something like Scrum or extreme programming can often improve productivity a lot of teams may be looking at Conbond as sort of an easier more lax approach so more relaxing whatever and that might be true but it might also hurt your productivity to give up the structure of this one I had the fortunate work on an extreme programming team for four years and extreme programming takes a lot of discipline and there's quite a bit of structure and it's really challenging but wow the productivity was amazing the fun was amazing it really really worked but it took a lot of commitment to do that some teams here at the foundation are using Conbond or something Conbond based something that resembles Conbond something Conbondish and then the final though is really every team is different so Scrum might be the answer Conbond might be the answer extreme programming might be the answer something in between all of that might be but every team should start somewhere and continually improve and get to where they need to be and I'll give you a quick sneak preview that there are some resources on the final slide other questions when you say the you know a disciplined approach to Scrum so you can really improve productivity are there specific parts of this process that you would pick out is the key things that are hard to do that really grab those improvements well I think looking at extreme programming it would be pair programming on everything all the time constantly refactoring your code and automated tests for everything that set and it is highly productive but difficult to do so that would be one example I think in the case of say Scrum vs. Conbond having the time box iterations that you estimate and commit to that requires some practice and some discipline and there are benefits of doing that but it can't be that much why would I have questions so Grace I think you said that there is some team, can you bring up a team that is using Kanban here because it seems like fortunately this Scrum extension almost has the pieces we need it has the limit in each column but I don't think it has the diagram with the two errors I don't think it has that sort of increment in backlog graphing right it does not currently have flow diagrams and in fact it doesn't have good burn out charts or burn down charts yet it has some form of those but we're not happy with them yet we're working on that so have you asked the Christopher Johnson guy in Germany if you could consider doing it there's a work underway right now to try to make that happen in the next month or so to get improved burn out charts in the next month or so keep it afloat with some time after that cool can you bring up maybe the team using it the team practices group does a Kanban-ish process the new discovery department that I worked with uses a Kanban-based process can you show it I'd be curious to see how you do it, do you actually call it backlog or do you have a separate board right so I think most of the teams that are doing it have one board for the product backlog which is the long-term roadmap and then a board for the equivalent of a sprint basically the one or two week horizon of current work being done I know for the discovery there's a series of sub teams so it's discovery something something sprint are the difference for different work being done boards and discovery has a product backlog as a whole yeah so in the case of discovery it was a new group and so we decided to start with a relatively easy process and figure out whether scrum is going to make sense for us or not in case of analytics they were unhappy with scrum and shifted to Kanban they just didn't work for us because we get interrupted so we would commit to do things in a sprint to find out that we couldn't deliver them because we had to take care of them having some live system and I think the teams are less stressed out yeah yeah Arthur has a question Arthur you can just unmute okay well he says how do you recommend managing continual improvement on Kanban team yeah what Rachel said yeah I don't have any brilliant answers to that retrospectives regular retrospectives the team would have to decide what frequency makes sense constantly encouraging the team members to be on the lookout for stuff that could be done differently better pain points all of that this is one of the places where Kanban has a tendency to kind of break down at least in its utility no fault of Kanban at all but I feel like where I've seen teams try to get up and running with Kanban they don't put anything in place in addition to the bare bones of what Kanban offers you to ensure that there is some understanding around supporting continual improvement on the team so I don't know if this is something that I would necessarily argue should be added to like a definition of Kanban but I would urge anybody that is wanting to implement Kanban on their team to at the very least in addition to the couple of things that Kanban says you should do make sure that there is somebody on the team who can own the responsibility for managing continual improvement on that team somebody who can periodically circle back with the team and say hey what's working well what isn't what can we do to actually improve what are the kinds of policies we can put into place on our team to actually address our pain points because without that then you just get stuck in this eternal rut of work and progress and that's about it yeah I think that makes a lot of sense and I would say Kanban doesn't tell you to have a product owner equivalent kind of a person who is doing prioritization but you probably should have someone like that and they don't say that you need to have somebody overseeing the process but it's probably going to go smoother if you have the equivalent of a scrum master kind of a person so yeah Kanban really is it's reduce your batch size slash width visualize your workflow and it's continually improved and if you're ignoring the continually improved part then you're only doing two thirds of Kanban so yeah I think that makes a lot of sense I think just to add to that really we're talking about things in terms of tight feedback loops and maybe this falls more under scrumban than kanban but having a regular even if it's not a person having a regular meeting like a retrospective is a good way to just assess where you're at and I don't see how that I mean that falls into the same categories as small batches and seeing things happen quickly so that you can adjust on the fly if you're not having those retrospectives or whatever you want to call them then you're not actually making that adjustment the process itself and we're talking about kanban as a meta process that fits yeah exactly yeah kanban kanban there's a lot that kanban doesn't say you have to do but you better find a way to be doing the stuff that you can do I'm still curious can you bring up the work board a fabricated work board using this kind of basically how do you do this CFD and measure your sort of cycle time with our current tools can you just not do it yeah the way the teams are my understanding of the way the teams in the foundation that are doing it are they're going about it is they're not really focused on the CFD they're not focused on the measurement and the predictability aspect it's really more we've got all this work to do and we've got to manage this flow of getting it done and get it done as efficiently as possible so I think as a starting point that's fine it works and there's nothing wrong with it but I do see over time wanting to at least be able to get those measurements and start to visualize better it's not a prerequisite but it would be a very nice thing yeah I could try to bring up a board here so this is just one of the sub teams on the discovery department and so you can see this particular one has pretty simple backlog essentially work to be done in progress is work that's being done needs reviews work needs been done is ready for the in this case the product owner to sign off on it and say yes actually these stories here have been resolved in fabricator so they're crossed out indicating that the product owner has already said yes they are done and done for the solvent do you ever take them off the board? yeah periodically we do sweeps and that's another question too is because Convyn doesn't have sprints they don't have these time box iterations we're still trying to figure out should we keep this board this one board forever or should we rotate it out once a quarter or should we rotate it out once a week we have weekly meetings we're sort of on a week with cadence so we haven't quite figured that out yet but yeah this board however long this board does exist we'll be clearing out the done calls it seems like you're using a combination of points and counts there so the background is obviously not for stories but you only have one story estimated so right so our discovery department which is only existed for less than a month really is we've sort of said we're not going to deal with story points yet and so whatever points are in there are one person chose to take the initiative to estimate something for his own purposes but it's not part of our full process can you change back from points to say just count the number of stories and say we only have five in progress it doesn't seem in other words can you forget about points just use five in progress six in the backlog or something that's what we do on action so I didn't know you could do that that's what I'm asking well this particular work board is being a sprint do you guys not do a sprint? we don't use the points field we have a little hack where we put it in the subject the title so we're able to limit the number of cards that are in different states I think if it's not a sprint board I think it just counts cards if it is a sprint board I think it starts counting points but I'm not sure yeah so is there anyone that's sort of responsible for making sure the tasks are well defined enough in small amount of matches or is that something that just sort of is just naturally occurs as the team practices right so Kanban and Scrum both tend to think of teams as being self-directed so that kind of issue would sort of get worked out by the team I would say technically the product owner if there is one would be responsible for getting the story to that state but at the same time whoever's pulling those stories in would be responsible for making sure that it is well defined before they pull it alright well thank you all very much for attending and great questions feel free to contact me afterwards and I will be posting the slides somehow