In this video, we're going to talk about estimation, and this can be a very dicey topic for a lot of teams. When estimation is used badly, developers are obliged to supply hours against tasks that they haven't really had a chance to decompose yet. And then they're blamed when they don't conform to those estimates for not working hard enough. That's the dysfunction that you want to avoid. When estimation is working well, it's something that you use to prioritize things, so you can ascribe a certain amount of value to a story. And if there are two stories of equal value, you probably want to do the one that has the lower estimate first because you can get it done. That's a legitimate use of estimation. And sometimes you need to have some coarse estimates about how much content you can finish over kind of a longer term. because you're trying to make some forward-looking decisions that you have to make to manage the company or the product in some fashion. Those are jobs that estimation is sort of a necessary evil. Now, let's look at estimation as a process. We want to maximize real-value added time. And the process of estimation is distinctly a BVA activity. Okay, it's helping us make decisions, prioritize stuff, and otherwise run the business. But, there's nothing about our estimates that are going to directly pay off to something valuable to the customer. Something we do to manage the business, so it's kind of overhead. So we're always trying to minimize BVA and maximize RVA. Now, there are those that say that estimates are bad. And there's a whole no estimates community that says don't estimate things. And then, as an alternative, they would probably say use short cycles, look at actuals from what you really did accomplish as you move through things and avoid estimates. There are alternatives to do all the jobs that you need to do that are better than estimates. Now, you may or may not subscribe to that idea, but you certainly want to try and minimize the amount of time that estimating and follow up on estimation takes. Now, let's look at how estimating relates to the various tasks that we've talked about in the job of deciding. Well, for prioritizing and batching tasks, you need to prioritize against cost relative to value, so there you may want some kind of an estimate, even if it's very coarse. And in terms of batching tasks, you need to know about how much content you're going to get done in a given iteration. So estimates, if you have them, would come into play then. When you share out responsibilities and tasks, you want to have a sense of magnitude as people work through things and so that you can divvy out work appropriately. And as you manage work in progress, you may want to have an idea about if there's a bunch of items moving through the system, are some larger than others? Why is this one sitting here so long? And as you define and communicate release content, you may need some kind of course estimate, so you have a rough idea of what content is likely versus not likely to be available to you at a given forward point in time, should you decide those are the right things. So, in terms of the jobs that we delineated here, I would say those are the places where estimates principally come in to play. One of the primary vehicles for estimation is the story point. And the idea is that this is a relative measure of difficulty that you assign to different stories or possibly tasks if you're working against tasks in your back log. And part of the idea of the story point is that it's not hours for a couple reasons. One, this helps avoid the kind of the fallacy of over measurement and describing more precision to these estimates than really exists. Two, the idea is that if you keep your story points the same relative to the size of the work. Then as you improve, you'll be able to see that while something that was three story points took this long and now we're improving so it's taking less time because we've automated, we've worked together better as a team. Gives you a backdrop for continuous improvement. So, here are some ways that teams will measure story points. Some use a minutes, hours, days, months scale. And obviously this is very course, but in general, course estimates are probably better. You're probably never going to have the exact granularity on these things that you would like. It's just not realistic in most cases. Most work is just not that obvious, most of the time. And the nice thing about a minutes, hours, days, months scale is if it goes to upper management, they're not going to ascribe things to these numbers that don't really exist and come back and surprise you and generate anxiety and so forth. T-shirt sizes is another popular metric. Good for some of the same reasons this is good. And then some teams do use numeric measures, for instance these are planning poker cards which we'll talk about in a second. And you can see that these use Fibonacci scale up to around here when the scale gets a little bigger. And these type of story points are often used for this game of planning poker and the idea is that developers, mostly from inside the team, will sit around and you'll talk about a story. Then everybody will put out a card at the same time. And the idea is not to average everything out or drive to a consensus immediately. The idea is that if there are big differences in everyone's estimates, then there's probably either some lack of clarity about what the narrative really is about. And, or some kind of lack of clarity about how you all would approach it and where it fits into the implementation scheme. So, you can buy planning poker cards online, you can make them, you could just use regular playing cards, and so forth and assign values to them. This is something that you might want to try, but again, the folks that believe that estimates do more harm than they do good would probably say, this is part and parcel with the activities that we think are not productive for the team. You can, on tools like Trello, you can either use a plug-in which will generate a estimate here somewhere, or you can just put them in brackets at the end of the story or task. It's a very common way to actually manage these are you're looking at your work in progress. Now, here is an alternative. So I've talked about how some teams believe that it's better to just look at your actuals, what you've done after the fact, after an iteration. And then calculate if you need rough estimates for something. Calculate your estimates on that basis. So, take stories you've done in the past and compare them with what's on the product backlog, and to the extent you need a forward-looking view of what you might be able to get done, that'll give it to you. So the way that this would work, if you're generating this cumulative flow diagram, that is a feature of Kanban and there's some notes in the materials and exactly how to tabulate that if it's not clear. This red or pink series here is items that are done. So if we calculate a line here, well, this would be our Burn Up line. So this is sort of an alternative to burn down. And this tells us, well, so overtime which is on the x-axis, generally how many story point have accomplished over a given iteration or period? And this can be an input into your forward looking estimation. So burn up is an alternative, not necessarily mutually exclusive but it often is, it's an alternative to using burn down. And it's particularly useful for these kind of course estimates you may need as you're defining and you're planning your release content. So, those are some thoughts, focal points and tools that you can use for the process of estimation. My advice is that if you see the need for estimates, err on the side of course estimates and avoid falling into the trap of ascribing more precision to them than they can really give you. Because that can be very destructive to the environment you're trying to create for a high functioning Agile team.
