In this video, we're going to talk about the job of prioritizing and batching tasks. You learned in the module we had about learning, that the user story map here is a great place to have a sort of focal view of your narrative and how you're going to interpret that narrative into your implementation. So, if you remember, the x-axis here is time and the y-axis is the priority of your stories. So, if we think of this as a narrative lasagna. It has these different layers here, slices, and the key thing, and this is probably the most important job that you have as a product owner in preparation for your sprint planning, iteration planning meeting is how do we slice the lasagna, not vertically like you would slice a real lasagna that you're going to eat, but instead, slice off the very thinnest top layers of narrative so that, let's say, these storyboard squares here are a single epic, just hypothetically. I'm not implying there's always three storyboards per epic or anything, but let's say it is, our job is to figure out what is the thinnest possible set of highest priority narratives that we could implement and create a coherent testable version of this epic. And, the reason why this is so important is that most constantly, iterations are run late, and you're not getting done everything you wanted to get done. This is normal, it happens to everybody. And, the typical thing is they blame the implementation team, they didn't work fast enough. That may or may not be true, it's probably not true, but the point is, is that if you're doing a good job as product owner, product lead, then you're slicing this really thinly, and so you may get several of these horizontal slices done during the iteration. But the point is, is that if you slice it thin enough, maybe this is only a quarter or a half of what you think you can get done in the iteration. And, you know that even if you run behind schedule, when you get a quarter or half done of what you wanted to do, you still have a coherent testable narrative that you can put in front of the user and observe. And, that helps you make sure that you're moving through the cycle that we talked about being so important. So, that is the most important job from a deciding standpoint for the product owner. And, the way that the housekeeping for this will often work is, if we use a Kanban board, and these are just some Trello boards, Trello is a very popular Kanban board tool that you may have seen. The product owner and the team overall is probably maintaining one board that moves from idea to product backlog, meaning stuff that's on deck to be implemented so that any idea that comes up or maybe a customer request, feature request. Those are all going into this board that the product owner is the lead or whoever is the customer in XP, whoever's doing that job, and then in the iteration planning meeting we have the sprint back log, or iteration backlog, and that's what we've decided we're going to work on in a priority order. And, then we have the different steps, implementing, testing, reviewing, calling it done, as we move through a given iteration. So, items will flow from the product backlog to the sprint backlog, and you'll work through them. So, this is how you can kind of keep this stuff organized. And, your job as the product owner is to constantly be sorting these, not in terms of functional area or generalized priority, but in terms of those sort of horizontal strips of lasagna, the thinnest possible implementations that you can get out for testing. So like this, and that's probably the most important thing. Now, how big should you make your iteration slices? So, should we do one week iterations, like they do in XP? Or, maybe one to six week, the variability that Scrum provides for. Well, a good guideline, I would say, it's better to start with shorter iterations. If you have more uncertainty, your team's new, the thing you're working on is new. That way you get small pieces out that you can test quickly, and you can learn faster about how things are going. And, everything else being equal, if things are more stable, maybe a longer iteration is okay. Another good way to observe, how well the iteration length is working for you, is that, if you don't even really have time to incorporate all the feedback you're getting about how all the things are going in iteration. Maybe they're too short, they're kind of burning too hot. And, if you're finding out things too late, which is very common, then maybe iteration length is too long. And, it's one kind of symptom you can use to balance and decide on your iteration length. If you're finding that you need a longer iteration because your, say, testing cycles are taking a really long time, that might be an okay temporary reason to make the iteration longer, but as we'll discuss here as we go forward, then you should probably look at why does testing take so long? Should we figure out a way to phase in more automation because, as we learned with the agile methodologies and as you'll hear from some of the case studies we'll talk about, automating the builds and testing and all of the things that don't actually have to do with writing code. That is one of the most valuable assets that if you ask a team, an agile team that is succeeding and happy, what are some of your most valuable investments, and if it's structural, they'll probably refer to that. So, that is probably not a good long term reason to have your iterations be long. So, those are some ideas of how long the iteration should be. We've talked about this super important task of slicing the content of the iterations in horizontal thin strips rather than going here and saying, well, let's just do all the search functionality first and then we'll move on. And, that is a really important skill that you'll develop in the product owner customer proxy role as you become a successful agile practitioner.
