In this video we're going to talk about the job of managing work in progress in an individual iteration or sprint. You can see here, this is the board for the HVAC and Hurry team on their initial iteration, this column is the sprint back log. This is the list of items that they've decided they're going to try to execute in the sprint. Sorted in the lasagna order that we talked about with nice thin slices of coherent narrative stacked on top of each other. The other columns here are working, so somebody's working on this. Testing, somebody's testing it. And then the product owner is reviewing it. They're doing kind of a final check of does this look like what we wanted, what we were thinking for this narrative. Did the test pass, the ideas we had about how to make sure. And then we have done over here. You can maybe see these individual numbers here like these are all one, this one is two. These are those wip limits that we talked about in kanban. And these are really important because this helps us make sure that we avoid stackups, that we're making our feedback loops perform by moving coherent pieces of work through the system. And the reason they're one, is it that there's only one developer now and she believes that she wants to move one coherent piece of work all the way through the system before she loops back and starts another one. And if you talk to practitioners that subscribe to kanban and lean, you'll probably find that generally speaking, they prefer that general approach of sort of one coherent piece of work moving to the system with an individual developer. Now in principle that works well for a lot of people. You may need a blocked column here if there's some external thing that they can't work through. And you want that to be visible and you may find that, you may find that you should extend the whip limits for some other reason for different situations and the principle of kanban would say that you should work collaboratively to evolve to the right web limits. Now let's talk about what actually goes in this sprint backlog here. You probably can't see them, but here on these individual items or cards I have put discrete stories. A lot of teams particularly scrum teams will instead take items off the, stories off the product backlog. Decompose them into individual development and test tasks, and then put those on the sprint backlog board. So the board you're looking at here. Now, what should you do? Or should you do a bit of both? Well everything else being equal, I'm, as you probably gathered, very focused on narrative and I think that's the best way to make sure that the work is driving something valuable that's going to be good for the team, good for the product, good for the company. Everything else being equal, I would say stories are probably better, they make sure that, for instance, if you have a whole bunch of tasks you can be moving them through the cycle here but all the stories get done at the last minute, right, because a task doesn't equal a story. Maybe you, by mistake, did the front end stuff at the very end for some reason. And from a kanban work in progress standpoint, that's probably less good. You want lots of working software visible, if you can have it, as you're moving through the cycle. That way you drive good discussions and collaboration. And another reason that stories are good is that if you have a product owner review here, I mean I can't really review an individual task. That said, the theory is that you're having those discussions and reviewing things as you go along and everybody is asking the right questions of each other. So you might find the tasks are better. You may find tasks give you the granularity you need. Now a lot of teams, particularly on web applications, prefer full stack developers, folks that can do the data controllers, the logic controllers, the database design, the front end, all that stuff because that way they can work on coherent slices of narrative. You minimize hand-offs and overhead. But that may not be your reality. You may have specialty tasks that need to be delegated to individuals. You may need that to be very visible on the board. In that case, use tasks. Or use a combination of tasks and stories, that's also okay. You don't have to necessarily choose. Another consideration is that you may need more granularity for burn down to see how you're doing over the course of the sprint. Some teams find that important, particularly if you're working on longer cycles. And that may be a reason why tasks function better for you. I'll also say that these columns are just examples. Kanban says, of course, that you should be realistic, look at what's really going on and be explicit about it, so you should make your own. A lot of small teams will actually just have columns that say, this is what Bob's working on. This is what Dana's working on, and that works best for them. It minimizes overhead, keeps things visible, it helps everybody have the right conversations together. If you're finding that that's the case, it doesn't mean that you've somehow failed the kanban or done something bad. It's fine. As long as it's working well for you and delivering, then it's probably the right decision. Burn down is also a consideration on work granular layer. You want to look at how things are burning down. And in principle the more granular the items on the board are, the more you're going to see your progress burning down here. But again this might be a little bit of an artificial view of things. If you are burning down lots of tasks, but you only really finish discrete stories here, and then everybody's like, no, that's not what we really wanted. Then of course, this was effectively wrong, assuming that the freak out of whatever nature here generates rework. So those are just things to balance and consider. So how do we tell if our work in progress is highly functional and working well for us? Well, on the prioritizing and batching tasks are we only seeing user stories completed in a way that we can review at the very end? If that's the case, then you probably need to look at how your work in progress strategy is performing and how to maybe make that better, because it's good to be able to keep the work visible and understandable throughout the process. In terms of sharing out responsibilities and tasks, is work stacking up, are some people kind of idle or fine, and some people are struggling with the amount of work they have? That might be a case to tune your work in progress strategy, mange your WIP limits, manage the granularity of items on the board. Those are all candidates for review if you're finding that. And then finally, defining and communicating release. Particularly if you're on longer iterations. You may find well you need more granularity about how you're doing so you can see if you're going to make or not make this iteration which is going to go into a release that has a bunch of contingencies. Again, I would say the best way to solve that particular problem is back on the product back log board with relatively more coarse estimates and that You're sort of seeing the disadvantage of longer cycles at that point, if this is generating a lot of overhead for you. But, then maybe your reality, and I mean that in the course of the duration, you want more granular tasks on the board. So, those are a few focal points and strategies for managing work in progress. The most important thing is that you have an explicit set of success criteria, I would say these jobs are good place to organize that, and that you're constantly getting better. You don't have to be perfect, but if you're not improving, your team doesn't feel you're improving, then that's a time to really step back and ask yourself why and figure out what to do. You have all the tools. You'll be fine.
