Agile Forecasting... WITHOUT estimates?

If you thought it was necessary to estimate in order to forecast, well, you are not alone. It's almost taken for granted here in our Agile world, that we start with estimates, mix them up in a certain way, and produce a forecast. It's just what we do. But what if we could forecast without estimating? Welcome to Development That Pays, my name is Gary Straughan, and welcome back to this short series on estimates and estimating. If you've been following along, you already know that I prefer you didn't estimate, but if we don't estimate, how on earth can we forecast, how indeed? We'll get to that in due course, but let's start with common practice. Common practice is to forecast via velocity. Velocity, as I'm sure you know, is the average number of Story Points delivered per sprint. Now, already you can tell I'm talking about Scrum. However, although some of the terms I'm gonna be using are Scrum specific, the general approach is not. I'll say more about that in a moment. As I was saying, velocity is the total number of Story Points delivered per sprint, meaning that if we can figure out the total number of Story Points in what it is that we need to build, then we can figure out how many sprints it's going to take. For example, if we have 1000 Story Points in total, and a velocity of 100 Story Points for sprint, divide one by the other, we're looking at 10 sprints. If we're doing two week sprints, that's 20 weeks. So far, so simple. I guess the only tricky bit is coming up with a value for velocity, and the way I was taught to do that is by plotting a graph. Sprints along the bottom, Story Points on the side, and I'm gonna plot the total number of stories delivered in each sprint. The next job is to come up with a line of best fit, and there are a couple of things to bear in mind while doing so. Firstly, what we're looking for, especially in the context of forecasting, is stability. That's something we're unlikely to get with a brand new team, or a team that's had major personnel changes. It's usually gonna take a few sprints for things to settle down a bit, and for that reason, I'm gonna ignore the first three sprints. Secondly, what we're looking for here is a horizontal line, this would be velocity decreasing over time, luckily, that's relatively rare, this is velocity increasing over time, despite what we'd wish for, this is extremely rare. So yes, a horizontal line, and I'm gonna fix it right around here. Looks like our velocity is, well, would you believe it? 100 Story Points per sprint. You know I like my nice round numbers. And now we have a value for velocity, we're ready to make a forecast. Let's say we have 1000 Story Points in the backlog, divide one number by the other, that's a forecast of 10 sprints, or 20 weeks if we're doing two week sprints. As I said earlier, some of the terms here might be Scrum specific, but the approach is not. What we're plotting here is the number of Story Points delivered in each sprint, but we could just as easily plot Story Points delivered each week. So if you're not doing Scrum, but you are estimating, you could use this approach, and the same goes for the approach I'm about to show you. But just because you could, doesn't mean you should. I'll say more about that later. There's another way of forecasting that we can do right on the graph, no arithmetic required. This axis doesn't change, still sprints, or weeks if you're not doing Scrum, but I'm gonna change this one from Story Points to cumulative Story Points. Exactly the same data, just presented in a slightly different way. Next up, finding the line of best fit. Velocity decreasing over time would look like this, velocity increasing over time, a mythical beast remember, would look like this. Constant velocity is what we're looking for, and that's a straight line, and it's gonna be easier to place it if I swap these bars for dots. As before, I'm gonna ignore the first three unstable sprints, and put my line right around here. At this point, I could get a value for velocity, believe it or not, it's just the gradient of this line. But I have another trick up my sleeve. The reason for the switch to cumulative Story Points is that it allows for a second line, the total number of Story Points in the backlog, which in this case is 1,771 Story Points. Whoa, what happened to the easy numbers? Never fear, they'll be back shortly. Okay, what are we looking at here? The gap between the two lines at any point in time, is the number of Story Points still to be delivered. At the beginning, well, they're all to be delivered, and that number reduces sprint by sprint, until we get to the end of sprint eight, where there is, oh, look at that, 1000 Story Points still to be delivered. I told you there was no cause for concern, not only a nice round number, but the same nice round number that we had in Method 1. Now, for the clever bit, I'm gonna extend these lines, I believe extrapolating is the technical term, and where they intersect, you know, cross, that's the point where the number of Story Points delivered is equal to the total number of Story Points in the backlog, meaning we're done. Looks like that happened at the end of sprint 18, we're currently at the end of sprint 8, and if we weren't at the end, we wouldn't be able to plot it. So our forecast is 10 sprints. That's the same result as before, which is reassuring given that we're looking at exactly the same data, but this time, we did it all right there on the graph. While we're here, there's a neat little refinement that I'd like to show you. If you've been around Agile for any time at all, you'll know that we're always adding new items to the backlog, and that's exactly as it should be. Agile, among very many other things, is a process of discovery. As it stands, we have a backlog frozen at 1,771 Story Points. What's more realistic is the backlog growing slowly over time, like this. Notice how this pushes the forecast a couple of sprints into the future. So that's two, two and a half ways of getting a forecast from estimates, but there is a problem, a fundamental flaw with everything that I've shown you so far. I wonder if you spotted it. I may have misled you by suggesting that getting the velocity is the tricky bit, getting the velocity is the least of our problems. In order to use any of the methods that have just shown you, it's necessary to estimate the entire backlog. That's something that even estimating advocates would hesitate to recommend. So have I wasted your time? Not at all. Allow me to introduce Vasco Duarte. If you've come across him before, chances are it was in the context of the #NoEstimates movement. We'll talk more generally about #NoEstimates another time. But I think it's fair to say, that Vasco made a major contribution to the #NoEstimates conversation, especially when it comes to forecasting, and it all started with a question, what would happen to forecasts if we removed all of the Story Point information? What would happen if all those twos, threes, fives, eights, thirteens, and on and on, suddenly became ones? It's almost a dumb question. Luckily for us, Vasco didn't think it was dumb, and he was prepared to put in the work to get an answer. That work began by getting access to a bunch of GIRO repos. Not exactly sure of his process, but I can see conceptually that having access to historical data like this allows for a spot of time travel. It's possible to go back in time, create a couple of forecasts, two and a half even, then move forward in time to the end date, and see which of the forecasts came closest to that end date. It's worth stressing, that without actual time travel, Vasco wasn't able to influence the data in any way. No telling teams to limit their Story Point range, no telling teams to slice their stories smaller, no preconditions whatsoever. It's also worth noting that Vasco wasn't limited to teams mad enough to estimate the entire backlog in advance, and that's because, and this is a little bit "Inception," when you get to the end date, everything will have been estimated, even if it wasn't at the beginning. I'll leave you to head scratch about that one. So for each repo, Vasco needed three things. A Story Points forecast, a #NoEstimates forecast, I'll tell you what that is in just a moment, and an end date. We've already been over two and a half ways of producing a Story Points forecast, and this is the repo data that I used to plot those graphs. As you can see, I've broken down the data for each sprint by Story Point value, A little bit of Excel magic gives me the total Story Points per sprint, and a little bit more gives me the cumulative version. Data to graphs, to a Story Point forecast of 10 sprints, or 12 sprints for Method 2 1/2. For the next step, we need some #NoEstimates data, and yes, I could change all the Story Point values to one, and let Excel do its thing. But there's a much easier way, all I have to do is count the stories for each sprint. Add an extra column for cumulative stories, and we're ready to plot, using exactly the same methods that I've already shown you, with a couple of tweaks of course, I told you I wasn't wasting your time. Here's the Method 1 graph for the #NoEstimates version, this axis stays the same, this one swaps Story Points for stories, that's a simple count of stories. Here's the line of best fit, giving a pseudo velocity of 12.5 stories delivered per sprint. Let's say there are 100 stories in the backlog, divide one number by the other, giving us a forecast of eight sprints, 16 weeks if we're doing two week sprints. That's different to the Story Points forecast, which shouldn't come as a surprise, we have after all, removed a lot of information. Okay, onto Method 2. This axis stays the same, this one changes from cumulative Story Points to simply cumulative stories. Here's the line of best fit, and here's the second line. This time, it's the total number of stories in the backlog. I'll extrapolate in a moment, but first I'm gonna move this axis to the other side so that I can superimpose the two graphs. All right, extend those lines to give us a #NoEstimates forecast of eight sprints. The same result as for Method 1 as we were expecting. I'd be remiss if I didn't apply the final wrinkle, the ever increasing backlog. Let's stay with this view. Two forecasts, both remember derived from the same data set. Two different forecasts, but which is better? Well, that all depends on the actual end date. If it's here, the Story Point forecast wins, if it's here, the #NoEstimates forecast wins, if it's here, well, I guess we call it a draw. Okay, back to Vasco and his real data in those real repos, what did he discover? Well, for most of the repos he looked at the #NoEstimates forecast was as good or better than the Story Points forecast at predicting the actual end date. To me, this is an outrageous result. Think about it, think of all the Agile teams in the world that have used, and continue to use estimates for forecasting. That's real people spending hours in multiple meetings in order to produce the pile of estimates required, and by pile, I mean the entire backlog. No time traveling benefits for them. After all that pain and suffering, I'd expect the Story Points forecast to be twice as good as the #NoEstimates forecast. Of course, for you, the pain and suffering might now be over. Thanks to Vasco's work, you now have options. If you are currently using estimates to forecast, well, your life, and the lives of the members of your team, just got a whole lot easier. If you're not forecasting, but would like to, well, you now have in your hands two and a half methods that are not only free from estimates, they are free literally, all of the data you need is already sitting in your repo. All you need to do is count stories and plot graphs. If you would like to know more about Vasco and #NoEstimates, you'll find a link to multiple videos in the description below. And join me for the next episode in this series, it may be this one here, although these things can be very difficult to forecast.