By Rebecca Jones
In The Board we talk about various Agile topics. This week we talked about Estimating. We discussed what story points are and and gave tips on how to make estimating stories easier. We also talked about why we estimate stories and long range planning.
Kirstin Donaldson: Hi, and welcome to The Board. Happy New Year to everybody. This is our 44th episode. I’m Kirstin Donaldson and I’m joined by Jesse Stegmann.
Jesse Stegmann: Hey guys, how’s it going?
Kirstin: Today we’re going to be talking about estimating. We thought we’d devote a whole show to estimating, because we did a workshop recently, where we had some quite long conversations around it. Some interesting points came up, so we thought we’d have a go and talk about that for 20 minutes.
Jesse: Yeah, absolutely.
Kirstin: One of the first things I thought we’d talk about is how stories are traditionally estimated using Agile. One of the things that people have a little trouble grasping is the fact that the sizes of stories are determined against other stories.
Rather than saying, “This story is large or small,” we compare it to another story. There’s a particularly good exercise we use in workshops — which I’m going to ask Jesse to explain, because that’s what I normally do…
[laughter]
Kirstin: …around using a graphical example. Rick, if you could put that picture up on the screen for us to use.
Jesse: What we talk about here is we’ve got a picture of the skyline of Hong Kong. If you look at the really tall building on the right, if I asked you to estimate Kirstin, if you could tell me how tall that building is, in meters.
Kirstin: Looking at it, it’s probably 200 floors or something like that, and each floor’s going to be, say, two meters, three meters high. I don’t really know. I’m not good at dimensions, but let’s say three meters.
Jesse: Three, yeah.
Kirstin: So 200 stories times 3 meters, 600. Is that right?
[crosstalk]
Kirstin: I think that the point I’m trying to get to is that I’m going to find it very hard to estimate that, and I’m not…
[crosstalk]
Kirstin: …but let’s say 500 meters.
Jesse: All right, cool. I have no idea. I’m just putting it out there, unfortunately. But what we can see there is it’s taking Kirstin a really long time to estimate, and she’s probably not got that close to an accurate estimate.
If I then said to Kirstin, “The building further right, with the purple roof, if we say that is 300 meters, relatively how big is the tall building we’re talking about before?”
Kirstin: If I compare one to another just visually, quickly I can see that the tall building is probably twice the size of the blue-and-purple building. If the blue-and-purple building is 300 meters or a three…
Jesse: A three, yep.
Kirstin: I’d call that building a six, or 600 meters.
Jesse: Cool. That’s a really quick example of how we can accurately estimate things using relative sizing. We understand that one piece of work, the smaller building, is a three. We think that the really tall building, the really large piece of work, is double the effort. Using the relative sizing, we’d then say it’s a six. We don’t have a six in our scale, so we might bump it up to an eight or down to a five.
Kirstin: One of the questions that came up during the workshop we were the other day on this was, “How do you know that how much the original story is to size it against, if it’s your first time starting out on a sprint?”
We had a couple of answers to that. One of them was that it’s quite hard if you’re a new team and you’re starting out on your first sprint. One of the exercises that can be done is using swim lanes. We’re generally, on a table, set out some blue tape lanes and put the size cards up top.
Our signs that we use are 1, 3, 5, 8, 13.
Jesse: To in the middle 1, 2, 3, 5
Kirstin: 1, 2, 3, 5, 8, 13 — maybe 13, don’t always use it. Pop those in, and then when you look through the stories with the team, the team decides which story might about medium-sized. Just for an example to put in the middle of those swim lanes on the five or the three, depending on where you think the middle is. Pop that in there, and then size every other story against that middle-sized story.
This isn’t something where you go ahead do all that. You’ll then stand back and review all those stories in the swim lanes. Have a look at the one you’ve got in the middle. Is that accurate? Does that need to move? Negotiate with your team members until you’ve got a batch of sized stories. This can really help you to get started on your first sprint.
Other techniques we use during the course of a project are planning poker, which I’m sure we’ve talked about before. The team holds those sizing cards in their hands, reads out the story and then finds a consensus on what that size is. That can be very difficult for a start, so that swim lane is a great way of sizing up a bunch of stories.
Jesse: Really quickly.
Kirstin: Just to get started. You can always go back and resize them if they’re drastically after you worked on them. That can give you a bit of an idea for future sprints.
Jesse: Absolutely. Just one point to note is this story that you choose to be your middle and first story, try and make that one that your team is relatively certain about their estimate — because it is your basis for your scale. If you get that first story horribly wrong, [laughs] in terms of the estimate, it can throw things off a bit. Try to pick something that’s fairly easy and the team are feeling confident around the idea.
I was also introduced to a new technique just yesterday. One of the teams that we are working with, the product owner did what he called a “story gallery.” he had a new feature and about 20 stories that he wanted sized. He got all the stories and he put them around a big meeting room.
The team went around, individually, read the story themselves. He was in the room, so each member could ask him questions about the story to understand each story better. Once they had a good understanding, they all sized the story individually. They just wrote down a number on a Post-It note, put it in a little box next to the story.
At the end, they quickly tallied up all the sizes. Anything that had a unanimous consensus, that was the size for it. Any stories where there was a big discrepancy, like in planning poker, they had a bit more discussion about it. He said that worked. In an hour, he got 20 stories estimated, and really well, too.
[crosstalk]
Kirstin: …would be a good idea. One of the other things that we covered the other day that came up, we were talking about why we plan for anywhere from one to four weeks for a sprint. Jesse, you had a good analogy for the reason why.
Originally, we were talking about the kind of uncertainty in software where, when you first start working on a feature, the gap between what you know about it now and what you know about it at the end is very, very wide. As you move towards the end of that build, goes down, until you get to the very end, and you know everything about the feature, including how long it took to develop.
At the start, it’s very had to do an accurate estimate. That’s one of the reasons you spend a whole heap of time to narrow down that estimate to hours and days. We just give it a size, but you had that good analogy when you asked someone a question about what they thought they might achieve.
Jesse: We were just talking about how, in a scrum, we limit our iterations to a month, usually. We prefer two weeks. Part of the reason we do that is it’s very hard to estimate beyond the month. If I ask someone what they think they are going achieve in the next three months, in terms of physical output of work — “How many proposals would you write in the next six months, Kirstin?”
Kirstin: How many projects can a scrum master [indecipherable 08:49] …?
Jesse: [laughs] It’s very, very difficult to give an accurate estimate. You’re probably are going to be up this end of the cone, where you might be way over or way under what you are actually going to achieve. If I then say to you, “What are you going to achieve in the next week? How many proposals you’re going to get…?” you probably have quite a good idea.
If I go even narrower than that, “What are you going to do tomorrow?” you can give me a really accurate estimate. Back it down again, “What are you going to do this afternoon?” even more detailed.
Kirstin: That’s why we plan for shorter periods. It doesn’t make us completely accurate, but we more chance of having a good view of how long things are going to take.
Jesse: A little thing with planning is acknowledging that, if you’re planning for a long-range estimate, maybe it is better to give a range. Say to a client, “We imagine this feature will be delivered in the last quarter of the year or of the project.” As you get closer, you can update that estimate to, “OK, we are going to deliver it in this sprint.” Then maybe during the sprint, you’ll have a release date for that feature.
Kirstin: One of the reasons we were talking about that is because, if we’re delivering a workshop on Agile planning, one of the criticisms we hear of Agile is the lack of certainty in project delivery dates, features delivery dates.
I would counter that with the fact that, in traditional projects, when you’re specifying everything up front and you’re doing a Gantt chart up front for the entire life of the project, what you end up with is a bunch dates that we would term wishful thinking. That kind of uncertainty is so wide at that point, that there’s just no possibility that those dates are going to be correct on a feature or epic-by-epic basis.
Developers are asked to commit to that wishful thinking. It’s very unrealistic. Whereas, if we are doing this shorter-term estimates, the likelihood is that people are going to be much more comfortable committing to that, particularly if they’ve been directly involved in making those estimates, via sprint planning and story sizing.
They’re going to be much more comfortable with saying, “Yeah, in likelihood. that’s what’s going to happen.”
Jesse: I also think, in that case, people are inherently positive with their estimates, especially long-range forecasting, and they don’t know. If you come to a developer and say, “Hey we’ve got this whole piece of software that we’re going to develop. Do you think it will be done in 18 months time?”
That sort of range seems realistic to anyone. You’re like, “That’s a really long time. It’s really complex but, sure, we can finish it in that amount of time.” Then people get held to that, which is unfortunate.
Kirstin: Of course, if you’re committing to something that’s supposedly is going to happen in 18 months time, that doesn’t account for being flexible and allowing change, and for outside conditions to change.
Perhaps the market might change, and the product you’re working on is now longer suitable for delivery. If you’ve committed in saying, “This is what it looks like and this is what’s going to be delivered,” it’s very hard to deviate from that, as we’ve seen on a number of large projects, certainly here in New Zealand.
Jesse: Yeah absolutely.
Kirstin: They have come out the other end and not been entirely suited to their intended purpose.
Jesse: The other thing is if you’re estimating those small chunks, grooming your backlog regularly, asking people to estimate small manageable pieces of work, you can then take that entire backlog and get a really good estimate on when you will be delivering things, without having to ask people for those long-range guesses.
Kirstin: That’s right, but then, as you mentioned a little bit earlier, the important thing is to keep revisiting this. Don’t just expect that to be written in stone for the lifetime of the project, which is what we see on those more traditional project management. Once you’ve got that date, that there’s no deviation from it. People end up having to work longer hours to meet it.
Jesse: I read a really interesting quote recently. Try and change your reports that you develop for your planning. Look at them not as a fixed document, but an update of the status of your project at a certain point in time. You know, in January…
Kirstin: That is what we’ve done.
Jesse: This is what we’ve done. Given what we know currently, this is where we think things are going to come out. Maybe you do that in January. Three months down the track, you produce another one and you say, “All right. Well, this is what’s changed. This is now where we see things going,” or “Hey, everything’s going really well, and we still think we’re on track to deliver these things, at these points in time.”
Kirstin: That’s really part of being transparent to the reality of the situation. The Board helps with that on a short-term basis. If you were doing reporting to state what’s happening, as opposed to what was supposed to be happening when you wrote it in stone three months, it’s more transparent.
People can make informed decisions from that. Whoever’s receiving it can say, “OK this is going to impact this, this, and this. And this is what I need to do, as a result.” I think there’s a tendency for people to…ignorance is bliss, right?
Jesse: Absolutely.
Kirstin: Sometimes people find it more difficult to be confronted with what’s happening, regularly. But, of course, those of us who work in that way realize that the mitigation that you might need to perform is, by the same token, smaller increments, and therefore easier to handle.
Jesse: Absolutely, absolutely.
Kirstin: There’s is nothing worse than…if someone has been not telling you about something for a long period of time and then you finally find out.
Jesse: [laughs] Getting a surprise.
Kirstin: It’s always more difficult to sort out the longer these things go on for. It snowballs into this massive thing to sort out.
Jesse: Hand-in-hand with that is a lot of people struggle with that concept of short-range planning, because their releases are often so big. They’re planning to release their whole product in a big bang, or a whole new feature in a massive big-bang situation.
Whereas, if you’re constantly releasing and making small incremental changes, that kind of thing makes it so much easier. You haven’t promised seven different clients all these features in your next major release. You might have checked off a few throughout your delivery. Maybe there are one or two people that you disappoint rather than a whole group.
Kirstin: And if something’s wrong with the code — hopefully there isn’t, but things do go wrong — it’s much easy to sort out problems on two or three features than it is on a hundred.
Jesse: Absolutely.
Kirstin: Trying to tackle…to which, as a more traditional project manager, you’d be familiar with that UAT period, which is the big bang we’re just referring to. We certainly have done it a number of times, where we deliver everything to the client, knowing quite well that some of it is not of great quality because we had to release it to meet the deadline — that wishful thinking.
Then the clients goes through, and checks it feature by feature and comes back with a massive list of bugs, which seems to go on for months and months afterwards.
Jesse: Absolutely.
Kirstin: In some situations you find yourself negotiating it out. If you’re working on these bugs for six months, we’re actually going to stop here and agree that we’re not going patch a certain amount, or whatever. It’s an unhappy situation all around. The developer’s not happy…
Jesse: Nobody’s happy.
[crosstalk]
Kirstin: …client’s not happy, and it’s incredibly stressful. We’re not talking about a job being the be-all and end-all and the cure for everything. Sometimes quality isn’t great on something for serious reasons. As I said, to fix it in small increments is much more efficient and manageable. It means that, when we do reach into the project, they’ll have working software that is of high quality, because we’ve been able to fix it as we released it.
Jesse: Yep, definitely.
Kirstin: Instead of reaching the deadline and having a product that doesn’t work.
Jesse: Cool. To bring it back to estimation — we got a little bit sidetracked — I had another conversation with another scrum master. He was saying his product owner was having a real issue with relative sizing, getting his head around it. He was very much equating one point to one day and points to developer days.
Kirstin: Is that what he had seen in previous sprints, he was starting to do that?
[crosstalk]
Jesse: No, he was very new to scrum and didn’t understand the relative sizing. I think a lot of people do that when they’re used to getting estimates in a time duration. They try and apply that to points, and sort of go, “All right. Well, one point is one day, two points is two days, and…”
Kirstin: Obviously, it takes a few sprints to build up, but more useful is looking at velocity. If the velocity is 12 points, it’s more useful to say, “OK, so that’s what we can achieve in a sprint,” thanto equate it with days. That doesn’t make that much sense to me, but maybe I’ve been working with Agile for a while.
Jesse: It was really interesting talking to the developers in that team, because they said, subconsciously, they’d had done that when they started. It was a new product owner coming into an existing team, and they were having trouble explaining what points meant to the product owner. They had started with the idea when they were new to it, but it had become, “Well, this is quite a complex story. This is not so complex as it should be.”
The one analogy that I really liked, that Mike Colin used in a blog post, is running. If two people are standing at the end of a trail, and one person says that it’s going to take them an hour to run the trail, another person says it can take them half an hour, they can argue and never reach consensus of how difficult…
Kirstin: How long it’s going to take them.
Jesse: …or how long it is, or anything like that. But, if they then change the conversation and say, “All right. Well, the trail is a kilometer long,” they can both agree on that.
Kirstin: So it’s talking about the size, not the time.
Jesse: Yeah, and the effort. If we bring that back to a scrum situation, the product owner won’t know how long it’s going to take a developer it to complete a two. One developer might take a day because they’re really awesome, another developer might take three days, but he understands. They can all have a conversation together about the fact that a two, for us, would be an average-sized story and a little bit of complexity, but not too bad.
Kirstin: Although I think it’s something to be splitting stories right down, and making everything a one or two. That actually makes it a lot simpler. It’s what we should be doing anyway, because smaller batch size increases productivity and decreases variability. It’s a good rule to stick to. Well, not a rule, but I think it’s a great patent to start evolving into teams.
Jesse: Yeah.
Kirstin: In that way, the product owner knows the size of all stories is going to be one or two, and they’ll get a sense for themselves how many of those they’ll achieve in a sprint.
Jesse: Yeah, exactly,
Kirstin: Another point is that it’s tricky if you’re working with a company that’s developed a product, and your product owner’s someone who also works with the company, because they are going to think about time. Whereas, when you work as a service industry like us, and we have clients from outside, I can personally, as general manager, as well as a scrum master, talk about dollar terms.
“Two weeks is going to cost this,” and then we can start to talk about what we think we can achieve in that two weeks. Then, at the end of that two weeks, they can look at what’s been achieved and think, “Do I feel this is giving me value?”
Jesse: Yeah. Absolutely.
Kirstin: That internal situation, a lot tougher though. They can look at how much it’s costing, but a lot of people wouldn’t think of it that way if they were working internally. They’re much more likely to think about it in terms of amount resource and time taken, as opposed to how much that resource costs.
Jesse: Yep.
Kirstin: Yeah, a different sort of opinion, depending on what sort of company you are and what you’re doing.
Jesse: The other thing is, when you are in that situation where you’ve got multiple teams either cross your organization or developing a single product, points shouldn’t mean anything across teams.
Kirstin: They’re exclusive to the team.
Jesse: Yeah, which is the really important thing. One team in the organization we’ve been working with, their velocity is about 40 points, but their average story size is eight or something.
Kirstin: Yes. It’s not like they’re working longer hours, or they’re…
[crosstalk]
Kirstin: …developers. They just have a different scale.
Jesse: They just have a different scale. Compared to another team, which is actually bigger, more developers probably get through more work, relatively, but their velocity is a lot less.
Kirstin: Like 15 or something like that.
Jesse: Yeah, because their stories that come into the sprint had twos and ones, as a general rule, but they’re probably the same amount of work.
Kirstin: That’s why there’s no point comparing teams’ velocities. Velocity is really something to help us plan and to help us explain to the product owner approximately how much work we’re going to get done during the sprint.
Jesse: Yep.
Kirstin: Again, relative to previous sprints, though. We might say it’s not just velocity, but total points for your sprint. We might say, “Last time we did 10. This time we’ve got an extra person. We’re going to do 15.” Relatively, we’re going to get through more work. The sprint’s really sized in a similar way to the way the stories sized against each other.
Jesse: Yeah.
Kirstin: Maybe it’s getting a bit complex now.
[laughter]
Kirstin: [indecipherable 24:53.20] enough. Probably a good place to finish, unless you’ve got any additional points?
Jesse: No. I think we’ve covered it.
Kirstin: OK. Hopefully, that was useful. If anyone has any questions, just drop us a line at [email protected]. Thanks for joining us.
Jesse: Cool. See you.
