Agile Estimates

Derek Neighbors: Welcome to another episode of the ScrumCast. I am Derek Neighbors.

Clayton Lengel‑Zigich: I am Clayton Lengel‑Zigich.

Roy vandeWater: I am Roy vandeWater.

Agile Estimates

Jade Meskill: I am Jade Meskill. Today I wanted to talk about estimates.

Derek: How long do you think it’ll take to talk about estimates?

Jade: It depends.

Clayton: Have you ever done this before?

Padding Estimates

Jade: I thought the answer was, “It depends” [laughs] . Seriously, we want to talk about what are the challenges with estimates for your teams, for yourself? What are some of the things that we struggle with? To kick it off, let’s start with padding estimates. How do we feel about that?

Derek: Pad them, definitely. All the time. As much as you can. As much as they’ll let you.

[laughter]

Derek: Unless I’m paying for the work, then padding’s not allowed.

Clayton: Padding is something that is ultimately unnecessary inside of an agile framework. For scrum, for instance, if I say I’m going to do this many points this week. I commit to something for this iteration, and then my estimates are wrong, and I get half of it done or whatever. Assuming that everything else went right, then, it’s just instant feedback where I can say, “OK. Now, I know I can only commit to…” It helps you modify things. Ultimately, it’s a moot point.

Negotiating Budget, Timelines and Scope

Jade: Why do you think it’s so prevalent that there’s certified scrum trainers out there teaching people to pad their estimates? Why do you think that they feel that’s necessary?

Derek: It’s because they don’t understand the point of an estimate. What I mean by that is still today, even in a lot of scrum implementations I see we’re really talking about wanting to be precise, instead of wanting to be accurate. There’s this big, “Our estimates have to be perfect, because we’re telling somebody that this is the estimate. When we tell them that this is the estimate, then they’re going to go allocate a certain amount of budget.”

When we tell them what that budget is and what that time is, they also expect to get every single feature that we told them as part of that estimate. As Clayton says ‑‑ when we go in and we get an iteration or two, we realize that maybe our velocity is not 20 it’s 15, we have a choice to make. We either have to spend more money, or we have to reduce the scope, or negotiate what it means to be done on the scope that we’ve already defined.

People do not like to have those conversations, because it requires being personable. It requires all parties coming to the table and having a discussion between people. I think as practitioners we like to hide behind tools, we like to hide behind code. We like to hide behind every technology known to man, short of having real conversation.

I think that product owners and business owners have a very similar problem. Because they don’t understand technology, they say, “You told me X, therefore X had to be true, just make it work. Work twice as hard, or work twice as fast, or do whatever and make those estimates right.”

I think it’s because we do a really poor job at the beginning of a project, or at the beginning of working with somebody, defining what it really means to do an estimate using Agile methodologies. What we were trying to is be accurate and be able to do some moderate planning, but we are going to have to inspect and adapt not only the way we’re doing things, but the length and the cost that it’s going to do those things as well.

Precise Vs Accurate

Jade: Let’s say that I am a product owner and I have a project that I would like you guys to do, and I need to know how much this is going to cost me? How long it is going to take? Here is my requirements, or my stories, or whatever it is that I have gathered for you. How are you guys going to give me any assurance at all that I can plan for this?

Derek: My two questions to you would be, how quickly do you need the estimate? How precise do you need the estimate to be?

Jade: What’s the risk in getting an inaccurate estimate?

Derek: The more precise you want to be, the longer and more expensive it is going to be, to get you an estimate. If you changed your mind on anything, or we discover anything new, we’re going to have to not do those things, or we’re going to have to go out and do all new estimates.

Jade: I’ve got a $30,000 budget, and I needed it done in four weeks. Can Scrum do that?

Derek: I think Scrum can give you a moderate picture of what the team believes they can do in four weeks on your particular budget, or I guess they could give you one or two things. They can either tell you four weeks what you will get for that budget, or they would tell you with your budget, how many features you can get done.

One of the two and I think that you can negotiate a fair amount of that feature set, and then have somewhat a good idea in every week. You will be able to potentially get feedback on how accurate those estimates were.

Jade: I want it all.

Derek: You should probably go to waterfall methodology then.

[laughter]

Tips and Tricks for Estimating

Jade: Estimation is one of the most difficult parts, I believe of being a good scrum team, is being good estimators. What are some tips and tricks that we can offer people to help make their estimates more accurate, help deal with these questions that come up from products owners?

Inspect and Adapt Prior Results

Clayton: I’d say that as far as becoming, say better at estimation. I would say really take the inspect and adapt concept, and apply that to your estimations too. I think a lot of times people do the padding thing, because they just pad everything. They don’t ever go back, and they don’t ever try and see, “Was I right?” Or “How far off was I?” Or anything like that.

It’s always just, “I’m just going to take, whatever I think it’s going to take, and I’m going to add 50 percent.” That’s their general rule. They don’t ever go back. I did that here with this team, and went into a sprints worth of tasks from every single project I think, and they were 300 or so.

Maybe it was two weeks of task, but we were off by an average of like half an hour I think. We were so close to our estimates, but at the time, everyone was saying that we are so bad at estimating, we did everything wrong. In reality, we were actually pretty close. We were way better than I think anyone would have thought.

I would say that if we can go back, and come up with some way to look back at your estimates and see either you are right, you went over or you went under, and why. Apply that next time.

Don’t Think In Terms Of Hours

Derek: I think one of the things that I see most teams do when they estimate, that really hurts them, is they are still way too tied to thinking in terms of hours. I’m trying to map what does a three point story look like in terms of hours? What does a five point story look like in terms of hours? Instead of thinking about them in terms of difficulty.

What I always like to say, is when somebody says that they are a bad estimator, usually what they mean is someone, either myself or somebody on the team, or somehow we derived a velocity that we thought was acceptable. We didn’t hit that velocity, and therefore our estimates were wrong.

What I like to say is, “Well, perhaps your velocity estimate was wrong, but were your story estimates really wrong?” If I say something is an eight, and something else is a three, and something else is a one. If that three is three times harder than the one, and the eight is eight times harder than the one or a little over almost three times harder as a three, I would argue that your estimates were spot on. Even if your velocity was off by half, or double.

That’s really where I see developers really getting hung up. Is that they get way too hang up on the velocity side, instead of how they are seeing stories and relative size. I think if they can nail relative size, you start to learn how to do velocity as you start to work as a team longer, and more together. You start to see what’s common.

I think we get way too hang up on that, that’s because we do fixed bid price kind of work, even we do internal work usually as scrum teams. We put a dollar figure on something that relies on the velocity never changing. I think that’s bad.

Make Sizing Relative To Reasonable Knowns

Roy: I think something we run into a lot as well is that, we had this mentality a lot of times going into doing estimates, where we’ve done a lot of reals application, specifically for us in the past. We start off going in to estimates with this notion that a CRUD operation is automatically a three. Then everything is based off of that. The thing is not every single project that you come into is exactly the same.

The skills are going to move all around, because what’s important is that, each story within that set of estimates is relative to other stories within that estimate. Not relative to any story outside of that.

Clayton: Yeah, I think the first time that became really abundantly clear to me is, I was working with an embedded engineer, and every single estimate was under a three. There were some things and I was like, “Dude, there’s no way. That’s going to take at least a week worth of work to do that, and you put a three on it.”

Then we went through an exercise to estimate the initial velocity, and the initial velocity for a week was five. It’s like, “OK.” You get used to working with a team who the numbers are probably more in the threes and the fives, or the eights, but the velocities are 25 to 30. Velocity really has a big impact to where your sizing story is as well.

Padding Skews Your Sense Of Reality Over Time

Jade: What advice do we have for trainers who are out there telling people to pad their estimates and use some multiplication factors? Things like that?

Roy: I think, ultimately, as a trainer, you’re hurting the team. If you’re doing something like that where they are padding their estimates, then they’re going to think of their estimates in terms of that multiplication factor.

If I estimate this as a two, and I multiply that times whatever figure, then when I go back and reflect on my estimates, I’m going to think about it in terms of the multiplied amount. I’ll be comparing the accuracy of my estimates against the wrong actual estimate.

Clayton: Yeah. I think it’s to the detriment of the people that are doing the estimations, and also to the people that are paying for the work. What I found is, when someone goes under on a task, let’s say that they thought it was going to take an hour and it only takes 15 minutes. When that happens, there’s never a revelation of, “Hey, I got this done so much earlier than I thought.” But when they go over, it’s always a huge justification of, “Oh, I told you that. This is why our estimates are always wrong, blah, blah, blah.”

It’s always like a one‑way street, and they don’t ever cancel each other out. When in reality, I think that’s what happens. It’s to the detriment of the people that are doing the estimations, because they don’t ever find out that they were right some of the time, and even though they were wrong some of the time, it was OK.

Jade: Yeah. I think that’s really good. I think that wraps up the podcast for this week. Thank you and we will talk to you again later.

Derek: Thanks.