To work in an agile way, we have to be able to estimate the amount of effort required to complete any requirement. But how do we do this? Well, the first thing to remember is that an estimation is always at its best, really just a guess. If we look at Steve McConnell's cone of uncertainty, which plots time against the error of estimation, we can see that initially, we will probably have a very large variation between the highest estimation and the lowest estimation. Over time as we deliver increments, our estimations will become much more accurate. So, the key thing then is, whenever you work with stakeholders or at the start of a project, is that you let them know that you won't be able to give them accurate dates, times, costs, etc. For exactly when the project will be delivered until the end of at least the inception stage. Instead, you need to say, we're going to work iteratively on incremental way to deliver you some of the project as we do that, we'll be able to really get a stronger idea of exactly how much longer will take us to complete the project. 

When you're estimating, it's extremely important that you do so in a relative way rather than an absolute way. Have a look at these three cubes for instance. I can't tell you anything about them absolutely, other than, they're cubes. But I can tell you that the cube on the furthest right seems to be the largest one, and the one on the farthest left seems to be the smallest. I can even say that the biggest cube seems to be about four times as large as the smallest one. It's easy for me to estimate the cube size relative to each other, but if you ask me how much the smallest cube weighed, absolutely in kilos or pounds, I don't have the information to tell you this. All I can say is that it looks about four times less than the biggest cube. We can easily apply this relative estimation to our requirements. We can discuss a project, compared with the work we've done before and estimate how large it is based on this.

Okay, so the question is about relative estimation versus absolute estimation. Well, if I was to brought before you 10 people of different sizes, different body matters, and asked you to estimate their body mass, wouldn't be able to do that with any degree of precision and there's a reason for that. Humans aren't designed to be able to, tap in with any degree of precision, people's body mass, and that is because you have to take into consideration the height, and it's difficult to estimate that, you know, visually their weight and then complete that into a body mass estimate. But if I were to ask you to, sort of grade, every single person of those 10 people in terms of their average body size in terms of small, medium, large, you would be able to do that, and that is because people can, you know, are able to make those kinds of estimates, because it doesn't require precision.

The next thing we need to do, is attach numbers to our estimations. This is really helpful when it comes to figuring out our capacity and velocity as a team. One of the best ways to give our requirements and estimation in numeric form is to use the Fibonacci sequence. This is because the sequence gets exponentially bigger the further up it goes, helping us to represent larger projects versus smaller ones more easily. Every number in the Fibonacci sequence is the sum of the two previous numbers, so, one, two, three, five, eight, 13, 21, etc. It's worth noting that planning poker games sometimes use an alternate sequence, that's pretty much the same, except that it goes to 20, not 21. And from 20, it goes up to 40, and then 100. It still roughly follows the same sequence and serves the same purpose. So, maybe we agreed that our smallest cube is one and our largest is an eight. Going forward, we now have a benchmark to estimate all cubes we encounter or in work terms, we have a way to put a number that represents the effort it will take for us to complete that work. Great! So let's talk about velocity. Velocity is simply the number of points we get done in a specific time. Let's say two weeks, maybe our velocity is 200. If we go into sprint planning and come out with a sprint backlog that has 250 points in it, we should know that we have overestimated how much we will be able to do, which means some of that work probably won't get done. We should only ever plan to work on as much as our current velocity allows for. Once our velocity is set and steady, we can also start to have a better idea of exactly when a project is likely to end. 

A great way to go about your estimation is to play a bit of planning poker. So this is really quite simple actually, everyone in the team gets a set of cards with a Fibonacci sequence on it. The stakeholder or product owner will present the requirements to us and each person will use their cards to vote for how much effort they think is involved to complete it. There will probably be some difference between the team on this, so we need to discuss it amongst ourselves, and then vote again until we can come to as close to a unanimous vote as possible. This method allows the whole team to understand what the work entails and to collaborate on understanding and estimating, rather than this sitting with one or two members of the team. So yes, that's that for this video. Estimation is just about a relative number you can use to understand the effort required in doing something. Relative estimation allows us to be as accurate as we can be, but still gives us the flexibility to change over time. It also helps us to build a velocity, which helps us to plan our work going forward. Planning poker is a great way to go about your estimations as it promotes collaboration and joint responsibility for the work we can do as an agile team.

Lectures

• Measuring Progress and Kanban
• What is a Project?
• What is Value?