What is planning poker?

I should have brought the cards. I used to manage the prop team, and I've recently transitioned over to ships, so that's why I'm here with these people now. So basically, I mean, it's probably not the most legit. I'm sure there are agile development experts out there who would shake their heads at how I do planning poker. Basically, you have a stack of cards. It's got numbers on it that represent values. I tend to just do it in days because art tasks are pretty easy to break down in days. But if you're doing more nebulous things, you can use a point system. It's kind of weird. I don't really like that. I like days as a measurement. Do you guys use story points for stuff?

We use points, yeah. The only difference really is, as you said, art is pretty straightforward and easy to estimate how long something might take, but engineering tasks tend to have all of this R&D and experimentation work, and it's very hard to guess. So we tend to quantify things in terms of the complexity rather than the time.

It's like a consensus on how crazy what you're asking someone to do is, right? It's not necessarily saying this is six months of crazy, it's saying this is 30 crazy, right?

30 points of crazy. Compared to other crazy things we've done, this one feels about the same sort of complexity as the other one.

So you could probably derive an estimate from that, but it's a bit different. Anyway, so that's a bit of a tangent. But basically, so you have these cards, they've got values on them. Everyone has their cards face down. And you say, OK, so we're going to look at how long do you guys think it will take to do the white box pass for the exterior of the ship, for example. And everyone will have a little think. They'll select their card. And then you say, show your cards. Everyone presents their card. And you basically look and see if everyone's got a consensus on how long it's going to take or if there's a massive deviance. And if there is, you say, Henry, you said it's going to take you 20 days to do this task. But John said it's going to take 10. Why is it going to take you twice as long? And then you might say, well, here's a bunch of things that John didn't think about. And then John might go, oh, OK. Or he might say, Henry, pull your finger out, mate. Come on. But basically, the point is that you've got the people working on a task, and you're trying to reach a consensus. It does take a bit of time as well.

I think in the past what we've tended to do is we've tended to do this on a ship scale. So we've basically looked at a ship as a whole and kind of gone, okay, well, we know another ship of roughly this size and this complexity, with a really well known art style or a completely unknown art style. We've kind of broken it down that way. Whereas what this allows us to do is the team to have more input into that. And also because the complexity of our ships has grown so much over the years, it's no longer a case of, oh, here's a small single seater and all small single seaters take X amount of time, because some of them have one wing that you can just mirror around. Other ones have completely unique parts and completely unique functionality. And it just allows us to get a better understanding of how long we think things are going to take and because of that, hit our targets better.

Compared to how we used to do it, it used to be at a high level, leads and directors would say, it's roughly going to take this long as a best-guess ballpark. Sometimes it's been so long since we've been actively doing some of the things that our estimates have fallen short, or new tech's made it more complicated or easier. So we don't have as accurate an idea of it anymore compared to the people who are doing it day in, day out. So we've had a couple of ships go through this process now and the estimates we've got from doing this have been almost to the day correct. And with some of them we underestimated the whole scope and cut back what we were going to do because we knew it wouldn't fit because of the better estimates, and everything got as much attention as it deserved, and we now know we just need to go back and revisit something else later, but we also know how much time that's going to take so we can plan for it better.

Yeah, we can adapt the scope of a project to the time we have, basically, because we have a better idea of how long each individual thing's going to take. So we can say, right, we've got 30 days. All this is going to take 40 days. Ben, what are you willing to cut? And then Ben will say, well, this task is 10 days, so we'll cut that. Better planning.