In this video, we're going to talk about the job of managing work in progress, and how it relates to the other jobs of deciding. One of the most important decision points happens every single day, during the daily stand up. And this is where, as you probably remember, all your team members answered these questions here about their work. And if they have questions, and they want to talk with each other about a detail, or someone else wants to talk with them, they take those things offline. With the kind of team sizes we've talked about between five to ten people, this meeting should run ten to 15 minutes. If it runs longer you're going to probably run into problems of people getting bored and not being really engaged. And so this is a place, particularly around this last question of am I stuck? Am I struggling with something? That hopefully your team is self-organizing, your team members are helping each other and this is an important point where you're helping yourself to manage work in progress. Now let's talk about how this works for basically getting material ready for a release and if you need to know that in advance. We talked about kind of these two boards here as being pretty typical of the way someone might Manage their work in progress. So if we have on the left here, we've got some idea. And all the way on the right here is we have this working software. Between these two boards we deal with this. This one deals with kind of preparing ideas and getting ready for implementation. And this one deals with actually managing ideas through a specific iteration of one to six weeks. Let's look at a little more detail at this product backlog, and how we get ideas ready to be implemented. And we've talked about that, but here, we'll go into a little bit more of the specific housekeeping. So, this starts with idea and then I've also put in a separate column, which may or may not be the right thing for you. With requests, these are basically externally generated ideas about things the product could do that would make sense, and then I made a separate column for discovery. These are things where the customer proxy, product owner, whoever is the lead on this, and not necessarily by themselves, but they're the lead on this. Is making the decision that, hey, this thing here might be a good idea, but we really need to go out and learn more about it and either texture it out or kind of preliminarily validate whether this problem that we'd be solving with this really exists. And then finally, this last column is the product backlog. Now, in Agile we do not, we at least try to avoid obliging ourselves to specific future content because we believe that by working in short iterations where we're constantly looking at whether we're achieving the right thing and what's important right now is better than trying to make the perfect plan. That question about look we need to know for x purpose what we're going to release in three, six, 12 months. That will come up and there will illegitimate and legitimate reason for it, but the illegitimate ones you may need to deal with and the legitimate ones you need to work through. So it's very common that in this product backlog item here, everything should still be sorted by priority from top to bottom. And it's very common that a subset of the working team will sit down and have a grooming meeting for this product backlog. And this is a couple purposes, one is to prep for the sprint backlog. But two, is to answer questions that you may have about long term planning by going through these and saying, all right, well, how would we approach this? And what is a very rough estimate, based on how well this story matches other types of similar stories that we've done in the past. I mean the best estimates are going to come not from future predictions, but from being able to look at historical velocity. And this is a thing that teams find themselves needing to do. It's very common. You'll probably do it. One of the things that's important is that this doesn't result in the idea that well we have our average that we finish an iteration is x. So, if an iteration goes below x, that's cause for alarm. The team's doing a bad job. I mean that's just not realistic that in the short intervals that you're always going to conform to that average. People have bad weeks, certain stuff turns out to be harder, external things can happen that slow down the work. So, this is a useful tool and generally legitimate approach to answering those questions. But, you want to make sure it's not generating artificial set of constraints around what everybody is doing because that will start to impede and destroy the good will and the trust and the discretion that the team feels that they have to do what they thinks makes sense. We learned about the courage value as a value of XP, for example, if you push the team to an artificial average, that'll diminish that courage because they don't feel empowered to do what they think makes sense. Those are some ideas about prepping the product backlog, and in the next video we're going to talk about how this moves to individual sprints and how we manage work in progress on those.
