BenP (00:00.936)
Hi everyone and welcome to the Tech World Human Skills Podcast. Now, this episode we are talking about estimating how long it will take you to do something, something I am particularly bad at. And to help us with this conversation, we have a business analyst, former principal software engineer and author of Dead Simple Python. Please welcome to the podcast.
Jason McDonald. Jason, it is so lovely to have you with us.
Jason C. McDonald (00:33.228)
It's great to be here, thanks for having me, Ben.
BenP (00:35.528)
no, you are welcome, you are welcome. Well, to all our listeners, I wonder, could we start the usual way? Could you introduce yourself to everyone?
Jason C. McDonald (00:44.204)
Sure. So my background is odd. As I said, I'm Jason C. McDonald. I started out in software engineering rather accidentally as a result of a traumatic brain injury, actually, which ended my dreams of becoming a doctor or pediatric pulmonosurgeon, as I used to say, as a four -year -old. That's how I would lisp it. I was age 16, had a traumatic brain injury, and had to change directions.
stumbled into computer programming, discovered that I loved it, whereas I had hated math previously, and started developing my own software, founded MousePaw Media, which is an open source organization that is still run on the side. WANAP accidentally started what turned out to be the... well, I started it deliberately, but I didn't realize at the time that it was one of the first four remote internship programs in the industry.
And then somewhere around 10 years into my career, I get a full time job as a software engineer because my disability had made that complicated up to that point. So my first full time job was as a senior software engineer, which is a weird way to start your career, let me tell you.
BenP (01:54.16)
Hahaha!
BenP (01:58.536)
And so then you've then been in software engineering and then you spent the rest of your time working in software engineering. Is that right?
Jason C. McDonald (02:05.964)
I did up until last year when I started realizing that you know what, I am starting to really burn out on software engineering. I had actually had yet another head injury in 2021 and it took...
It took a little bit of work to figure out that the reason I was burning out is because my brain changed again. And so I switched from software engineering into business analysis because ultimately what I loved most about software engineering was the communication part and people and coordinating work and how ideas go from, you know, client to project manager to the developers into the code and then to the user. That whole process is fascinating to me.
BenP (02:48.168)
Yeah, yeah, yeah. brilliant. Well, what an interesting background and thank you so much for taking the time to join us and looking so smart as well for everybody on audio. Jason is sporting a full bow tie and braces. Definitely worth checking out the YouTube video if you want to see the full attire from Jason. So, so. brilliant. Well.
Jason C. McDonald (02:58.38)
Thank you.
Jason C. McDonald (03:07.084)
Yeah, I'm gonna - yeah, and I've got the sonic.
BenP (03:15.72)
Let's start to dig into the main topic we want to talk about today. And so that's around this idea of estimation. Something I am, you know, I said it in the intro, really bad at. In fact, as we sit here this week.
I am late delivering something that I wanted to deliver a few weeks ago because I underestimated how long it was gonna take me to do stuff and bit off more than I could chew. So something that I am in desperate need of. So should we start to dig into this topic and start to think about, you know, why do you need to estimate? What are the common tools around today? What's the problem with those? And then, you know, spoiler alert, I think you've got a better way for us to start thinking about how we estimate how long it takes us to do stuff.
us to do something. So, shall we start off? Why do we need to estimate stuff?
Jason C. McDonald (04:11.244)
Well, in general, when you're gonna do a job for someone, their first question is gonna be usually either, how much is it gonna cost me or when is it gonna be done? And if you're building a house, it's a little bit easier. If you're building a bridge, if you're doing something that's very material, it's a little bit easier because, you know, there's certain things that are easy to repeat, you know.
Sorry. There are certain things that are easy to repeat. If you framed up a two story house once, then you got a pretty good idea how long it's gonna take you to frame up a two story house of a similar size a second time. Give or take a little bit of time for some variations.
But when you start talking about things that are more abstract, for example, software development, although there are certainly other things, you know, we have, you know, data science now, we've got all of these different fields that are immaterial. We're still building something. But...
It's not that tangible, repeatable, measurable thing like a house or a bridge or a car. And that lends to the complexity. I do like to often point out the software engineering in particular is really just the art of translating from human to computer speak. Translating an idea over. Translation, even between human languages, is fraught. It is complicated. It is because you have all these new ones.
BenP (05:39.272)
Okay, yeah.
Jason C. McDonald (05:49.886)
nuances and meaning you have to fully understand the source material. You have to fully understand the language you're moving into and how those nuances translate and so you get all this uncertainty. It's not just clean. You can't just say, I just gonna take me this long because think projects of this size always take me this long. It depends on the nuance. So estimation is necessary because it's the process by which.
we look at the task we're gonna try and do and ultimately answer the question how much energy is this going to take? Because if we know how much energy it's gonna take, then we know how much time and how much money, you know, we're looking at roughly. If we don't know how much energy it's gonna take, we're up creek. We're completely lost in the weeds at that point. So.
The challenge has always been though, how do you estimate software? And for the longest time we haven't had a good answer.
BenP (06:51.24)
And so what is, I mean, you know, I've heard the term, not worked with them much myself, but I've heard the term from within the agile framework story points. I mean, I'm sorry, I know that's one around today, but what are the common tools that when we're working in the tech world that people are typically using today to estimate how much energy, so how much time and money it's gonna take us to do something?
Jason C. McDonald (07:15.66)
Right, well, and there have been many attempts. So going back far enough when software engineering was still in its infancy, they were trying things like number of lines of code written, which becomes disastrous because it rewards inefficient code. You know, that's probably where the Ullman bracketing came from. You put the bracket on a separate line, it's worth more money. I don't know.
BenP (07:33.992)
Okay.
BenP (07:39.624)
I'm out.
hahahaha
Jason C. McDonald (07:43.98)
I'm joking at this point, but I have a sneaking suspicion that may not actually be a joke.
You could also try, let's reward how many features we've built, we ship, or how many bugs we fixed. But then you slam into something called Goodheart's Law, which is that anytime you turn a metric, and I'm not quoting it directly here, but anytime you make a metric into a target, then that metric ceases to be useful because people start aiming for that target to jump industries. If you're working in sales and you make lead generation your target, you need to
generate this number of leads suddenly your sales department is no longer closing accounts they're just generating leads.
BenP (08:27.272)
Yeah, yeah. So I've come across this in another form, really short, you get what you measure. So whatever you're gonna measure, that's what you get. So that's really therefore really important to choose what you do measure and to choose that very carefully.
Jason C. McDonald (08:34.26)
Exactly.
Jason C. McDonald (08:42.124)
Exactly. So recognizing that that was not working.
Then the next thought was, well, what if we were to measure things relatively? This is where story points came from. It's the idea that instead of saying that this particular task in software engineering is this big, you know, is this fixed number, we should say, well, it is larger than that one. So adding a new button to the website is smaller than adding the login feature, but it is bigger than changing the font, just for an example.
BenP (09:15.624)
Yeah.
Jason C. McDonald (09:15.646)
And that was in one sense revolutionary because for the first time it was possible to actually get a grip on all that nuance without having a way to measure the nuance. The challenge was we still weren't measuring the nuance. So it's a little bit like the early measurement systems. Our measurement term, the foot, the imperial foot.
It's not a coincidence that comes from the king's foot, which means if you change kings or if you change kingdoms, the foot is a different length.
BenP (09:54.568)
How dare they, those kings, have different sized feet!
Jason C. McDonald (09:57.516)
And there was actually a really good example of this going horribly awry. This was early standardization of measurement. 17th century, this massive warship called the Vasa, and this is a favorite story of project managers should bring up because there's so many things that went wrong with this project, but the king commissioned this massive warship called the Vasa to be constructed.
There was a ton of things that went wrong, but ultimately the ship sank 20 minutes after it was launched. It took years to build. Super expensive. They launched it 20 minutes later. It sinks in calm seas. And the reason, one of the reasons, that it ultimately buckled under its own weight is that they found out they'd used two different rulers. They had used the Swedish foot and they had used the Amsterdam foot, which are slightly
different. And so the ship on one side was actually using longer timber than on the other side.
So this is where relative measurement really bit them in the butt because one of these leftovers of the relative measurement, the fact there were these two different systems of measurement, meant that the ship was now lopsided by construction. That paired with all the other disasters and all the extra stuff they piled onto the ship, the decorations and whatever, and the heavy cannons, extra cannons, talk about feature bloat, the ship could not stay up and it just sank.
in 20 minutes. So relative measurement can be very very dangerous as soon as you have to go across teams, as soon as you change people, as soon as you go across projects, relative measurement ceases to work.
BenP (11:46.12)
Okay, okay. So we've got, I guess, a real challenge in that it's really important that you kind of are able to predict how long some it's gonna take and how much it costs. I mean, we're just getting our bathroom remodeled and redecorated as I sit here today. And that's how he makes his business. He tells me how much it's gonna, how much it's gonna cost me. And then that's how much he charges me to do the bathroom. And so it's just a vital part, but there's...
all these intrinsic problems with the current methods, whether they be story points that we've got in something like software development or just the general methods that we're using. So is there a better way, Jason?
Jason C. McDonald (12:30.54)
Yes, there is, and I stumbled across this quite unexpectedly. My journey with this starts all the way back.
with when I was first entering into software engineering, I picked up a book in the library called Dreaming in Code. I was looking for programming books. Came across this one. It reads more like a fiction book, although it's the true story of the development of a rather fated open source project called Chandler, which was the brainchild of Mitch Kapoor, who was the creator of Three to One Lotus, one of the first computer spreadsheets. And...
BenP (12:49.032)
Okay.
Jason C. McDonald (13:03.596)
Chandler, you know, they tried to build it. It was this revolutionary personal information management system. It was going to be open source. It was going to be awesome. And ultimately that they shipped one version that didn't work the way they wanted the project wound up scuttled. but.
Along the way, while they're developing this, Scott Rosenberg, the author, details all of the things that went wrong with this project. One of the things he points out is the fact that there were tasks on the task board that he referred to as black holes. Black hole is a task that never gets completed no matter how much energy you throw into it, which is weird when you think about it. Why would there be a task that no matter how hard you work at it, it never gets smaller? But that's the nature of software engineering. That's why estimations
so hard is because weird things like that are they just are. They really do work that way. And Scott made an interesting observation. He said within the first five minutes of working on a task most software engineers can tell you whether or not it's a black hole.
What that told me is that our instincts were picking up on something objective about that task. There was something there that we could look at. And it's the same thing that we're looking at when we're doing story point estimation. Because we're looking at something going, hmm, this smells big. I don't know why it smells big, but it feels bigger than that thing over there. So that got me thinking, if there's something that we're picking up on,
There has to be a way to quantify it. There has to be questions that we can ask to be able to make this repeatable.
Jason C. McDonald (14:44.428)
And that's kind of what started me off on this journey. So I wound up over my career developing three questions. And I have found that those three questions give a pretty solid picture of any task, software engineering task or other tasks. I actually use it. I manage a community now, manage an open source community, and I still use this actually even for those tasks because it allows me to
BenP (14:53.96)
Okay.
Jason C. McDonald (15:14.334)
to figure out how much energy a task is gonna take. Yeah, I'm building up all this tension for it, yeah. Okay, so the first question you wanna ask is how long would it take me to complete this task if I knew everything? So you wanna start by basically looking at the busy work involved.
BenP (15:18.92)
Okay, I wanna know the three questions. What are the three questions? Yeah.
Jason C. McDonald (15:41.964)
Most of the unpredictability around software comes from the stuff we don't know. So let's get all of that out of the way for a moment and just assume we know everything there is to know about this task. How much...
Shall we just say pure typing is involved because some tasks it'll take you five days of research and five minutes of typing. Other tasks will take you five days of typing and five minutes of research. So you start by looking at that. And this also is helpful because it gets the relative factor of personal experience out of the question. A junior and a senior developer will estimate different
times for a task if you just say how long will it take because the senior knows more than the junior does about that technology probably. But if you say if you knew everything you remove that subjectivity and they can arrive at pretty much the same answer in a very short space of time.
So I like to measure this. Everything in Quantified Tasks is one to five. It's just nice little sliding scale. Just makes this a lot easier to reason about and the numbers are going to be very helpful. Yeah.
BenP (16:57.48)
And can I just pause you there, Jason, because I think you've just introduced quantified tasks, you called this. So is this, and we've not mentioned that, I don't think yet, before on the podcast. So quantified tasks, so this is your approach to estimating, and it's a name, and you've given it a name, quantified tasks. And it starts off with the first question you ask yourself when you're thinking about this quantified tasks approach is, if I knew everything, how long would it take me? Okay.
Jason C. McDonald (17:03.404)
Mm -hmm.
Hahaha
Jason C. McDonald (17:11.788)
Yes.
Yes.
Jason C. McDonald (17:20.876)
Mm -hmm.
Right, exactly. Yeah. Yeah. No worries. Thanks for catching that. So yeah, you measure this relative to if you're using sprints, use your sprint length for the relative scale. So distance one is going to take, it's going to be within a day of work.
BenP (17:26.024)
Okay, carry on, sorry, carry on.
Jason C. McDonald (17:45.548)
Distance to is within a quarter of a sprint. If by the way, if you're not using sprints, just use it. Use a, an arbitrary timeframe. If you have no idea, use two weeks. Just pick something that works for like a.
development cycle length. Distance 3 is within half a sprint, distance 4 is within a sprint. 5s are always special in quantified tasks. Distance 5 means it's going to take longer than your sprint or longer than your development cycle, which is actually an indicator that you need to stop and break this task down further into smaller pieces. So it's a nice early warning to that.
BenP (18:14.6)
Okay. Okay.
BenP (18:20.424)
So I'm taking this in the non -software development way, because I'm not doing software development at the moment. So for me, that's gonna be right. So just break it up into days, hours, whatever is an appropriate unit, given the sort of size task that I'm talking of, and then just start to think, if I know everything, how many hours, days, weeks is that gonna take me? Got it. Yep.
Jason C. McDonald (18:25.996)
Mm -hmm.
Jason C. McDonald (18:38.22)
Yeah, roughly speaking. Yes. Make sure that when you're working with a team that everybody on the team is using that same time frame.
BenP (18:48.744)
Okay. Okay.
Jason C. McDonald (18:48.908)
That is very important. So if you decide, you know what, let's measure everything relative to a day because of all of our stuff is, you know, stuff that takes a few minutes to do at a time, then everybody should be using a day. Although honestly, I think a day is probably a bit short. A week is probably the smallest unit of time that's reasonable here.
Okay, so the next piece starts to deal with some of the uncertainty and it's what I like to call friction. So friction is a measure of the available resources or lack thereof to help you complete the task. Again, the point is to remain objective because it's easy to say, well, this has a lot of, you know, this has a lot of things I don't know. And this has a lot of things I don't know. But then you're back into subjectivity because someone else may understand the whole space. But
A junior and a senior can again agree. Is the documentation there? Has someone written down a process if you're working in software? How healthy is the code base? You know, is it like really easy to read code or is it really esoteric and was written by three drunk research students over spring break? You know what? Where is it in terms of the basically the things to help you or the things to slow you down?
That's what you're measuring. So I like to be in keeping with the name friction. I like to use terms related to streets. So friction one is highway. This is just this is tutorial that you could follow a guide online and you're done. Friction two is street. There's good reference materials. Bring your own brain, but it's relatively, you know, relatively straightforward. You could you could piece it together with all the information you have.
Friction three means you got some reference materials, some support, maybe there's someone you can talk to, but you're gonna need to bring some innovation now. You're inventing some. Friction four means you're inventing a lot. There's very little to help you. Friction five means you're on your own. You're in the jungle. And I realized I dropped off saying the titles here. So it goes from highway.
Jason C. McDonald (21:04.94)
Street, off -road, trail, and then finally jungle. Jungle is where you're on your own, Mr. Hunt. This ticket, issue ticket, will self -destruct in 15 seconds. You know?
BenP (21:09.384)
Okay.
BenP (21:15.816)
Okay, gotcha. Right, so first question we've got is, right, first question is if I knew everything, how long would it take? Second thing is what's our level of friction from highway all the way through to jungle?
Jason C. McDonald (21:31.308)
Right. Using GF documentation subject matter experts on hand etc. Yeah.
BenP (21:36.2)
Okay? Okay.
Jason C. McDonald (21:39.18)
Third, there's a saying from story pointing, make your best guess and multiply by three. And it's the idea that there's all these unknowns. So you can look at something and go, that should take me a week. But you don't tell your boss it's gonna take me a week. You tell your boss it's gonna take you three weeks. Why? Because you never know when you're gonna slam into something completely unexpected. You don't know what you don't know.
BenP (22:05.8)
Yeah. Yeah.
Jason C. McDonald (22:07.98)
But as Scott Rosenberg pointed out, again, there's something, really early on, you can smell that uncertainty. You can smell that weirdness right out of the gate. So the third question is, well, the third measure is called relativity.
and what you are asking is how much do we know or not know? How much uncertainty is there is the real question. How much uncertainty is there? The analogy I like to use is think of your task almost like a route along a map. And I love to use the analogy of the Hobbit by Jarrow Tolkien. You can measure how far it is from the Shire,
BenP (22:50.536)
Okay.
Jason C. McDonald (22:59.308)
to Erebor, the lonely mountain. That is 300 miles, by the way, in the book if you're a Tolkien geek.
BenP (23:05.736)
Bye.
Jason C. McDonald (23:07.66)
But that's assuming you don't run into anything. So that's your distance, 300 miles. That's your distance. Your friction you're looking at, okay, we got some mountains here. We can stop for help in Rivendell. We can see Bjorn the bear man. Mirkwood's gonna be slow going. Like you can spot the areas of friction. Relativity relates to these areas where you don't know how long it's gonna take you to get through there because of everything you don't know.
Passing through the mountains is what I like to call it a flux bridge. It's a bridge of indeterminate length. So passing through the mountains, you don't know how long it's going to take you, especially if you fall down a hole and deal with goblins. You could be down there for days or years. You have no idea. You go through Mirkwood. If you stay on the path, you're probably fine. But what happens if you get pulled off the path? You know, it's so again, you have no idea. You have no way of knowing until you're in the situation, whether it's going to take you hours, days, weeks, months, years, or maybe you'll
never come out. You don't know. You can't measure bridges of unknown length, but you can count them.
You know how many of these places of uncertainty are there on the map. You know you have to go through the mountains. You know you have to go through Mirkwood. And the reason, by the way, in the book, that Gandalf sent them through Mirkwood is because there were three points of uncertainty along the lower route of the map. They would have had to deal with the mountains still, but then they would have had to deal with three very treacherous crossings that were known to be crawling with evil creatures. And it couldn't go through the north because
there was no crossing point. And so that entire area was a gigantic flux bridge. So Gandalf was literally doing this in the book. He was thinking, how many points of uncertainty are there? Let's minimize those. So that's what you're doing with relativity is you're asking how much uncertainty do we have? Relativity one means there's virtually no unknowns. It's the Shire to Rivendell. You're...
BenP (24:53.224)
Okay. Okay.
Jason C. McDonald (25:12.556)
Actually, it's the Shire to Bree. There's no unknowns. People go that route all the time. Relativity 2 is low flux. There's a few things you can identify that you don't know. That's like Bree to Rivendell. You have to deal with the Trollshaws. There's some unknowns there. That's about it.
Relativity 3 is moderate flux. There are several unknown factors, but it's still feasible to complete it. That's going across the mountains. People do it all the time, but there's a lot of unknowns. There's uncertainty there. Relativity 4 is significant flux, which means that you cannot go that way unless you find a way to reduce your uncertainty.
It's just there's just too many unknowns. Otherwise, that would be getting through Merckwood. You had to find a way to and that's why they stopped over at Buren's. That's why they took the route they did, because it was the only way to reduce the uncertainty enough to get through the forest. Relativity five, again, fives are special. The black hole. There is no way to complete this task. Give up. Go back to the drawing board, figure out another way to do this, because what you're looking at is literally actually impossible.
BenP (26:17.16)
Yeah.
BenP (26:23.4)
Okay. Okay. So we've got three questions. And so I guess all of them are on a one to five scale. So you answer all of those on a one to five scale, one being really easy, five being really hard. Is it then that you've now add those up? Is it as simple as adding those up to get your estimation or is there anything else we need to think about?
Jason C. McDonald (26:32.044)
Yes.
Jason C. McDonald (26:36.492)
Mm -hmm.
Jason C. McDonald (26:47.148)
It is basically now just plugging it into the equation. So energy points is your composite unit of estimated effort. And I want to pause briefly and point out that it's called energy points and not story points because your actual limiting factor is developer energy or human energy if you're not dealing with software engineering. If people are tired, you cannot give them more money and have them find more energy.
If people are tired, you cannot make them stay the weekend and have them pull out a miracle. They're tired. They're out of energy. That is your actual limitation. I mean, that's why we're seeing 32 -hour work weeks taking off is because they're discovering by just not exhausting everybody, people get more done. So energy is the real budget that we are working with here.
And by the way, that's also why that phenomenon of don't ship on Fridays happens because people are tired on Friday. They're more likely to make mistakes. It's not the Friday specialist that people are worn out.
BenP (27:51.816)
Yeah, yeah, yeah, yeah.
Jason C. McDonald (27:53.1)
So since energy points is the limiting factor, that's ultimately what we're moving towards. And if you think about it, everything we've been talking about at this point is related to energy. How much typing is involved, how much research is involved, how much uncertainty is involved, but it's all related to your energy. So you plug those three numbers into the formula of adding distance and friction together, and then multiply that sum by relativity.
So let's just say if it's a distance three friction two, it gives you the number five. And let's say it's a relativity two. Your energy point score is then 10. Now the funny thing about this is energy points looks a lot like story points. In fact, you can drop it in place of story points. It works in all the same places. It works the same way. It even has roughly the same curve as the Fibonacci numbers that people love to use for story points.
But where it becomes really valuable is that this is repeatable across every team, every project.
Instead of just comparing only on the one team in the one project where once you leave that your story points no longer make sense. Energy points is repeatable which means people can form personal relationships to those numbers. When I am planning out my involvement in a software project I know I can do roughly if memory serves roughly 23 energy points per sprint if I'm working on Python.
and that is my average. That's my average velocity. That means when we're planning out work, if I take on 20 energy points worth of work, I can pretty much estimate that's gonna be done this sprint. And I use this with the team for about a year.
Jason C. McDonald (29:49.836)
where we were using this consistently and we were finding that our estimations were almost always spot on because we were getting used to our own capabilities in relation to those energy points.
BenP (30:01.128)
Yeah, so you then find that some people might be 15 energy points in...
a sprint cycle, some people might be 30 energy points, some people might be 23. So, but actually those energy points that are a relative measure that you've got to, so you couldn't start using this system tomorrow and go, right, we're just gonna move to this. You basically need to move to the system, operate for a while, which allows you to calibrate the system. And then once you're calibrated, then you can start to use it in the future to say, actually,
given the energy point, that means it's gonna take 10 people, 12 weeks, which will cost this amount of money. And so then you can get to the more tangible money date type estimations, which is what the real world needs to sort of function.
Jason C. McDonald (30:51.756)
Exactly.
Exactly. And more importantly, this becomes a part of the feedback loop.
So these are numbers where if you have things going wrong, where you can use these numbers to figure out where things are going wrong. So let's just say you've been missing deadlines on a regular basis. Your team has been struggling to deliver for some reason. So you look at it and you just realize, okay, we're just not able to get that much done. And you look at your average. So look at your averages. Your averages are really powerful here. You look at your averages and you realize your average distance is high. Your average
Friction is low and your average distance is high. That just means you probably need either more staff or you need to eliminate things that are sucking energy away from the team. Whereas if you looked at the averages and found that your distance was middling, but your friction was high, then you need more seniors or better documentation or more subject matter experts, whatever, staff training. So it becomes the beginning of the conversation.
BenP (31:53.352)
Yeah. Training, staff training, you know, that kind of stuff. Yeah.
Jason C. McDonald (32:00.494)
on how do we improve our velocity. You keep those numbers, you don't just put the energy point score on there, you also keep those three numbers, distance, friction, relativity. On the website, quantifidetasks .org, I have usage patterns for monday .com and JIRA, but there's other task trackers this works with too, where you actually set this distance, friction, relativity, and it calculates energy points for you. So you always want to keep those because you can look back and you can see why is this supposed to take so long or why is this taking so long.
Why are we stuck on this? And that's where the real value of this starts kicking in. It gives numbers to decision makers where they can start identifying how they can remove blockers. Just for example, if you're noticing your team's average velocity is suddenly dips, let's just say your team's average velocity is 25, and then suddenly it goes down to 10, 10, 10, 10, 10.
What happened when it dropped? we implemented that new meeting policy. that's sucking energy away from our developers. So it becomes an indicator of your developer energy, how much energy they have available for their work. It literally becomes a productivity measurement tool, not such that you want to drive them to always increase their numbers, but such that you want to create an environment where their numbers are not being driven down.
BenP (33:25.304)
Yeah. Jason, fascinating stuff. I have just glanced at the clock and I think we are heading very quickly towards the end. Really interesting way to look at estimating. Just as we start to wrap up, what would be your key takeaway? So people have been listening to this wherever they've been listening to this and now are jolted back to life as we wrap up. What would be the key things you'd want them to take away?
Jason C. McDonald (33:54.508)
I think the key thing is if you are struggling with estimation, definitely go to quantifytasks .org. That's where you can find more information about this. Pardon my clock. Yeah.
BenP (34:06.248)
Okay, it's chiming in the background.
Jason C. McDonald (34:10.38)
but go to quantifidetasks .org. It teaches you how to use this. But I think the other key takeaway from this is this isn't a magic bullet. There is no magic bullet. But Agile was never meant to be a magic bullet. Agile is about giving the power back to your developers to find what works for them. So introduce this as a possible tool for them.
even strongly encourage them to try it out for a while. See how it helps them. But the important thing about Agile is let the developers guide the process of what works for us, what is working and what isn't. You cannot impose change top down and have it work. So if you're finding yourself stuck in your processes, ultimately you need to look at how can we allow our developers to see what's going on and tell us. That's why this
works is this communication tool.
BenP (35:06.632)
Yeah, really interesting. As I sort of reflect, you know, just taking away those three things and the way I've been thinking about it, you know, how much work is it? How hard is the work? So, and then how much unknown? And sort of the way you've been talking about is distance. So how much work have we got? What's the distance? Then how hard is it? You know, that friction and the highway. And then what are all the unknowns? That relativity piece.
Great great way to think about it. I've never sort of structured and broken it down in that way before and I can think Hopefully if I start to estimate a little bit better I'll say maybe not yes to so many things Which therefore means that I'm missing deadlines on things that I'd say I do so Really interesting. So Jason for anybody that wants to find out more about this or get in touch Where can people go?
Jason C. McDonald (35:48.268)
Yeah
Jason C. McDonald (36:03.66)
So the best place to learn more about this is quantifidetasks .org, which I think you said you can stick in the show notes. But yeah, quantified, Q -U -A -N -T.
BenP (36:12.168)
Yes I will.
Jason C. McDonald (36:17.42)
I F I E D. I know it's hard to hear that sometimes. It sounds almost like Quantify. Yeah. Quantifiedtasks .org. If they want to know more about me, my website is codemouse92 .com. There's more information about some of my other projects as well as my book Dead Simple Python. If you want to learn the Python programming language and you already know how to code, definitely check that out.
BenP (36:19.624)
Okay. Yeah.
BenP (36:42.44)
Brilliant. Well, Jason, thank you so much for taking the time to be with us. It's been lovely to find out all about this and lovely to get to know you better as well. So thank you so much for all of your time.
Jason C. McDonald (36:54.22)
Thank you. Thank you for having me on. It's been a pleasure.
