PostHole
Compose
Login
SE Radio 599: Jason C. McDonald on Quantified Tasks
Jason C. McDonald, author of the book Dead Simple Python, speaks with host Samuel Taggart about leveraging quantified tasks to improve estimation, particularly across projects. They discuss the origin of the concept and its relationship with story points, and Jason offers examples to show how quantified tasks can capture nuances in software tasks that are often lost with story points. He also points to the ability to compare them across projects as a major advantage of quantified tasks. Among other topics, they consider also how to use quantified tasks to analyze the stability of a codebase. Brought to you by IEEE Computer Society and IEEE Software magazine.
Jason C. McDonald, author of the book Dead Simple Python, speaks with host Samuel Taggart about leveraging quantified tasks to improve estimation, particularly across projects. They discuss the origin of the concept and its relationship with story points, and Jason offers examples to show how quantified tasks can capture nuances in software tasks that are often lost with story points. He also points to the ability to compare them across projects as a major advantage of quantified tasks. Among other topics, they also consider how to use quantified tasks to analyze the stability of a codebase. Brought to you by IEEE Computer Society and IEEE Software magazine.
Show Notes
Transcript
Transcript brought to you by IEEE Software magazine and IEEE Computer Society. This transcript was automatically generated. To suggest improvements in the text, please contact [email protected] and include the episode number.
Sam Taggart 00:00:19 For Software Engineering Radio, this is Sam Taggart and I’m here today with my guest Jason C. McDonald. Jason is a software development manager, speaker and the author of Dead Simple Python, among some other books. He’s the founder of Mouse P Media, which is an open-source software organization where he trains software development interns. So Jason and I are here today to talk about something he’s developed called Quantified Tasks, which is a replacement or alternative for story points. So Jason, let’s start with talking about story points. What they are, where they came from, what people use them for.
Jason C. McDonald 00:00:53 Sure. Yeah, happy to be here, Sam. So story points comes from the Agile methodology that is, that came out of the Agile methodology, specifically Scrum. And the idea was to be able to estimate how long it was going to take to accomplish a particular task or a release. As soon as I say how long, of course all the Agile purists are screaming, no, it’s not about time, which that’s the goal is it’s not supposed to be about time. But in practice, when you implement Scrum, when you implement story point estimation in an organization, that is what it becomes about because managers want to know how long is it going to take us to ship this code? So story point was devised as a way of measuring how much effort it was going to take to accomplish a certain goal, a certain task. But because we don’t have something like inches or pounds or hours or some sort of handy metric that we can use to measure the size of a task, they instead decided to measure it kind of in the imperial way.
Jason C. McDonald 00:01:57 If you think back before we had the standard metrics, everything was measured relative to something else and usually the king’s foot and throughout, throughout Europe, ergo the imperial measurement of the foot. So story point is a way of measuring tasks relative to other tasks. So you come up with some fairly arbitrary scheme of numbers. You have one task, you give it a number, it almost doesn’t matter what number you give that first task and then you measure everything else in relation to that task. Is it bigger or is it smaller? Which is an interesting idea, but like with the foot in imperial times, it lacks standardization, it lacks repeatability, it lacks objectivity. As soon as you change kings or in this case teams, your measurements are suddenly very different.
Sam Taggart 00:02:49 Yeah, well I remember reading the book The Agile Samurai, by Jonathan Rasmussen. I think that’s the right author’s name. And it had something in there where it talked about how from psychology we’re really good at measuring, at looking at two things and telling which one’s bigger, right? So that relative measuring we’re pretty good at, but the absolute measuring of saying, okay, this one’s bigger than that, but which one’s — is this 1.9 and this is 2.1 or like what — it’s a lot harder to do that.
Jason C. McDonald 00:03:14 Yes, exactly.
Sam Taggart 00:03:15 So I think that, yeah, that’s some of the psychology behind it. So what scales do people usually use for these? Like I’ve seen all kinds of stuff from like numbers, Fibonacci sequences, t-shirt sizes. Have you seen anything else? Or are those pretty muchÖ
Jason C. McDonald 00:03:29 Those are basically in a nutshell, anytime you’re dealing with a numeric scale, what’s preferred to something with some sort of exponential or at least non-linear growth. That’s why Fibonacci’s so popular. And it’s funny when we say Fibonacci, because it’s not Fibonacci, it’s usually a modified Fibonacci sequence where they add a number that they drop and I can’t remember exactly what, but they, they’ve modified the Fibonacci sequence to be a cleaner exponential curve. And it’s the idea being that the larger the number is, the more distance there should be between that and the next number. The reason for that being, the larger the task, the more likely is there’s something uncertain in there, something you don’t know, or you don’t understand. So the difference between a task that’ll take you 10 minutes and a task that’s going to take you an hour or between a Fibonacci one and a Fibonacci two is very small.
Jason C. McDonald 00:04:20 But the difference between a task that’s going to take you, and again, I know everyone’s cringing that I’m using time here, but again, that’s what it ultimately boils down to. A task that’s going to take you a week versus a task that’s going to take you two weeks, there’s a huge difference between the two because you don’t know what other things you don’t know. You don’t know what you don’t know. The more complicated the task, the more effort involved, the more unknowns there probably are. Probably massive asterisk here, which is again, where things get a little bit wibbly wobbly, timey, whiny.
Sam Taggart 00:04:54 Yeah. What I always talk about estimates and stuff, I always try to think plan on short intervals. The shorter interval you plan on, the more certainty you can have, right? Like if I wake up in the morning and say, this is what I’m going to do today. I can be certain about that. If I say this is what I’m going to do next week, well there’s a lot of time that passes between now and then and a lot of I could get interrupted. My plans could change completely.
Jason C. McDonald 00:05:14 Right. Short cycles being one of the key principles of Agile.
Sam Taggart 00:05:19 So my next question is what do the current approaches fail to capture? Like you created this alternative, why did you create this alternative?
[...]