By Rebecca Jones
In Episode 31 of The Board, we talk about:
Full Transcript
Gavin Coughlan: Hello, and welcome to another episode of “The Board.” I’m Gavin Coughlan, Agile coach here at Boost Agile. Today we’re going to be talking about a couple of controversial topics. No estimating and programming are the topics we’ll be covering today. I am joined by you two.
Kirstin Donaldson: Kirstin Donaldson.
Paul Flewelling: And Paul Flewelling.
Kirstin: Thanks, Gavin.
Gavin: No problem.
So yes, we’ve been talking a little bit about these topics today, particularly the no estimating. Because lots of you have been using scrum for years, and estimating has always been quite a big part of that, but there’s been a movement. Would you call that a movement?
Paul: Yes. I’m not surprised it’s called the no estimates movement.
Gavin: Yeah, they took some time coming up with that.
Paul: It’s interesting. We brought this up a couple of shows ago because one of the Scrum teams I work with they raised the fact last year that they’d like to stop estimating. They got their stories down to between one and three story points. They’d realized that estimating was just becoming an overhead for them.
There isn’t that much difference between the story that’s size one and the story that’s size three. It flows through their system pretty fast. They were focused on flow, which is where this was coming from. They wanted to get things in small chunks and flow through their system as quickly as possible.
It’s interesting, there’s a guy called Woody Zuill. He’s quite a humble guy and he would say that he wasn’t the first person to come up with this idea but he is seen as the person at the forefront of the current Agile and No Estimates movement.
The idea is that you focus on de-coupling the stories which is the invest model. You’ve got the independent stories that are broken down into small chunks of value that you can deliver quickly and flow through a team and don’t focus on estimating just get it through the system.
This has all started because estimates after all that kind of uncertainty so regularly on the board. The kind of uncertainty shows that the further you are away from completing something the more variability there is in the estimate.
Break things down into small chunks à la Kanban and you have a much better idea of how quickly or…
Kirstin: I’ve got a question about how it works in practice. Sorry to interrupt. I haven’t read much about this, admittedly, so I’m really here to ask questions today.
My question is, during estimating the teams normally get to discuss the story a bit more and things are revealed about maybe previous experience and the stories [indecipherable 3:02] a bit more. When does that happen if you were to do away with estimating?
Paul: I think there’s still an opportunity to discuss the story before they head into a sprint.
Kirstin: At what point? Can you describe that?
Paul: During a backlog refinement meeting.
Kirstin: And then?
Paul: You wouldn’t have the estimating part of that but you’d still have a discussion.
Kirstin: What happen during sprint planning?
Paul: During sprint planning they would go through the stories in priority order and they’d…
[crosstalk]
Kirstin: Spread them and talk about them.
Paul: Talk about them, task them up and then commit. Particularly a big story for example that they weren’t comfortable with, they would recognize that through the tasking.
They’d see the number of times they were adding would be a great indication of how much effort or complexity there was in that story. Then they could determine what to do with the prototype at that point.
To be honest with you, that’s the way our sprint planning sessions had been running more and more recently.
Kirstin: Because the estimate I presume is fairly quick and agreeable?
Paul: Yeah. That’s right.
Kirstin: Given they are all [indecipherable 3:59] , too
Paul: Yeah. We’ve done a lot more estimating during sprint planning, which isn’t always the best way to do things. Because the prototype is delivering stories, those stories are in small enough chunks and the team is able to…
The refinement meeting is more a discussion about acceptance criteria.
Kirstin: Let’s take the project you’re talking about. You’ve always had separate sizing meetings, estimated meetings.
Paul: Yes.
Kirstin: It’s slightly different from the way I’ve normally done things. I normally just put it in with sprint planning for the much smaller project?
Paul: Yeah, that’s right. But for a new team, for someone who isn’t used to scrum, the sizing can slow things down and those sprint plan meetings can last for hours, which they can do.
Kirstin: [laughs] Yeah. Depends, but sure. That means if you did stop estimating you would eliminate one meeting for scrum.
Paul: No, I don’t think you would.
Gavin: We still have the backlog refining meeting.
Kirstin: Is that when you normally do your estimating during backlog refining?
Paul: Yeah.
Kirstin: So it’s not a separate meeting for backlog refining?
Paul: No, it just happens at the moment. The team has moved forward since this approach because we got a new product owner in the mix and they’re changing things up a bit. They’ve got to do a lot of fresh stories that they want to…a fresh way of doing things. We will move back to our refinement meetings. We are going to move back to our refinement meetings.
Kirstin: What’s the case with the new product owner?
Paul: Sorry.
Kirstin: You’re having backlog refining meetings with the new product owner?
Paul: We will be. Yeah. We just haven’t yet.
Kirstin: You haven’t had one yet.
Paul: It’s only been two weeks.
Kirstin: Is this new product owner…will he be providing the kind of small stories that you’re used to or you’re going to have to work on coaching him on breaking down stories?
Paul: I think we look fine at the moment on it. It’s working well still. The stories are still of the same size.
Kirstin: OK.
Paul: The backlog refinement meeting is still important because I still think that it’s important that the team see the stories at least once before they have the sprint planning.
Gavin: That’s interesting because a lot of the time in the backlog refining meeting, we’re trying to get stories down to smaller chunks.
I know you had a conversation with this guy who’s behind the no estimating movement. He said, “Well, rather than making stories small, aim to make stories…” What is it, decoupled, discrete?
[crosstalk]
Kirstin: [indecipherable 6:15]
Paul: Chunks of work.
Gavin: Yeah. That in turn they’ll become small, but don’t just try to make them small for the sake of it.
[crosstalk]
Gavin: You have to first try to make them discrete and decouple them. He had the third criteria. I can’t remember.
Paul: Yeah. That’s right. I can’t quite remember that one. The essential thing here is I see so many people who try and break stories down and delivering no value from the first story that essentially delivering a layer or a component kind of approach. They don’t have a vertical slice of work being delivered.
We often advocate the use of that story-splitting flowchart that is available through “Agile for All” and where to get the flowchart. It gives you five or six different ways of splitting stories that they’ll deliver value for that smaller set of stories.
Gavin: That’s a really useful flowchart for people who are having problems splitting up stories because, invariably, we go into teams who are new at Scrum.
They almost always seemed to feel that’s impossible to split up stories. That’s rarely the case. It’s difficult when you have to work with it, but it’s rarely impossible. I see it’s decoupled cohesive discrete. If you work to get your stories like that, they should in turn become smaller.
Kirstin: This means that stories shouldn’t have any dependencies either because what he’s saying here is that they can potentially go anywhere in the sprint.
Paul: Yeah.
Gavin: Another thing he addressed is because obviously if you’re to choose not to estimate your stories, you’re not going to have a velocity. That’s something that I…
Kirstin: Yeah. We were talking about this yesterday.
Gavin: I do agree with this because I try to impress on our teams that the velocity is for the team and not for the product owners to take away because sometimes they attach monetary amounts to story points and velocity.
Every concern of their velocity drops. They want to keep seeing their velocity raised. I think it can be a bit of an impediment having that velocity in there.
The more I impress that this is for the team and the longer a team is together and becomes a high-performing team, I think they start to disregard the velocity themselves. I think it becomes a bit of a useless metric really after a while.
Paul: Yeah. It comes to the point where if there was any focus on velocity at all and we’ve done is from our own experience, then the team will raise that velocity without doubt. What they’ll do to raise their velocity is increase the sizes of their estimates, for example. That’s one way they can gain in the system.
Kirstin: We just got a comment…sorry…from John Lowe, a former Scrum master at Boost actually who says, “Interesting. As a Scrum master, I find the team rarely gets all the meetings.”
[laughs]
Kirstin: What would you guys say to John? Personally, I’d say maybe you need to look at the meetings and how effective they are and maybe how interesting [laughs] as well in order to sort of encourage…
Gavin: My advice to John is just to be better.
[laughter]
Kirstin: Which we wouldn’t tell everyone, but we know John quite well.
[laughter]
Gavin: OK. Well, if they are reining against all the meetings, I suppose we have to look at the reasons why. Are they getting value from those meetings? If they get value from those meetings, then hopefully they should see that and stop resisting them.
Paul: You have to show them the value, John, and compare it to the old way of working, which is the alternatives are still meetings.
Kirstin: Having meetings with no outcomes.
Paul: Meetings without outcomes or meetings that you’re not involved in as a team member or decisions are made for you and based on someone like a senior developer or a team lead that’s gotten much more experience. It’s not the reality.
They can’t work on every single bit of functionality that’s being built. Someone else has to build it. If you’re involved in those estimates as a group, at least you get to state what you think is a reality for you and not somebody else’s reality or somebody else’s ability.
Kirstin: Is there an exercise that we’ve run to sort of show that? I mean, even just the rope game quiet simply shows what happens when the team takes responsibility for solving problems as opposed to a project manager.
It might be useful to run an exercise with your team.
Gavin: You mentioned a self-organizing team there when you mentioned the rope game that is well related to your conversation with Woody about the no estimating, because your team raised that they feel the estimating is an overhead at this time, and they don’t really see the value in it.
Woody suggested that if the team feel that it’s an overhead, then it is overhead, and it needs to be addressed, because if we don’t actually address it the team’s going to feel like they’re not being heard, and they’ll just get disappointed.
Kirstin: I was just going to make that a point. John said that interestingly we missed one planning meeting in the sprint. It fell apart, which is not surprising at all. I mean, if you don’t have the sprint planning, you don’t really have a sprint. Do you?
Gavin: That’s great to hear. I mean…
[crosstalk]
Kirstin: That does, because that would just show the team that it’s essential, right?
Paul: Following from what Gavin was saying as well, some people would approach it…If the team wants to remove one of their meetings, let them set that up as an experiment and then report back on how it works.
If they want to take out their retrospectives, sure let’s try an experiment while we don’t run retrospectives.
Kirstin: Which of course we did on a project here, an internal project…
[crosstalk]
Paul: …Let’s try…
[crosstalk]
Kirstin: …And we soon found that the team wanted to the product owner things, but didn’t have a forum to do so…
[crosstalk]
Kirstin: …So they brought it back again.
Paul: The problem with that, having a retrospective of course, is how do you communicate what’s not working for you, if it isn’t working…?
[crosstalk]
Kirstin: …That happens in a really ad hoc way.
Paul: That’s right. The way that we demonstrate the value of retrospect is, for example, the ball game. We play the little ball point game I think it’s sometimes called. Even, the paper plane game, it shows the value of all of these meetings.
Kirstin: Interacting and communicating…
[crosstalk]
Paul: Get them to play the paper plane game.
Kirstin: Get in touch if you want a description of the paper plane game and how to run it.
Paul: The velocity thing. Just going back to that and the fact that, obviously, management likes to know what the velocity is so that they can do a number of things. One is be assured that they’re getting some value out of this approach. They want to measure team’s productivity in some way.
Kirstin: Sometimes they need to communicate that to other people.
Paul: That’s right. The second thing is they want to do essential things like release planning.
Kirstin: Absolutely.
We were talking yesterday. If all the stories are the same size, then surely your velocity just becomes how many stories you’ve completed.
Paul: That’s right.
Kirstin: It might be 10 stories as opposed to 20 points. There’s still a way of having a velocity. It just looks slightly different.
Paul: What his argument is is what’s more important is actually getting the value stream up and running.
This is just going back to sort of the basics of agile fluency where you get the team focused on value, you get the people who are feeding the work to the team focused on value, and then you get the value flowing through your system as quickly as possible and getting it delivered to its endpoint as quickly as possible.
The next stage is to look at how you can measure that, if you want to measure it.
You have to perform at least two or three sprints before you can get an idea of the team’s velocity. It doesn’t usually stabilize until around five. Five sprints in, you’ve then got the ability to measure something.
Even with no estimates, you can still take this approach, and make sure the stories are tracked. Like you said, using those kinds of criteria that Woody gave earlier, deliver that value, and then work out how you can measure the team’s productivity if you need to measure the team’s productivity.
Gavin: One thing that Woody said which I found interesting as well was ask the question, “Has the product owner ever reprioritize the story based on the estimate that was given?” If the answer is, “No,” then what value do the estimates actually have? If the answer is, “Yes,” then that shows that they’re really just prioritizing cost-based criteria, which isn’t ideal.
I know I’ve brought this situation up before in the past shows, but I’m bringing it up again, because it’s relevant.
I was with a team who had 400 stories, and they wanted to estimate all the stories before they even started any sprints. They had two sprint zeros. They wanted to estimate all those 400 stories, because they had to report to somebody and tell them how long this is going to take.
They wanted to give a velocity before they started to do any sprints as well. It’s sort of a guess, an estimated velocity as well, which was a pointless process because we hadn’t even started working on any of these.
We’re spending a lot of time estimating stories that weren’t going to possibly get built and that we didn’t know anything about. That was one example of the…
[crosstalk]
Kirstin: Then, of course, the client would’ve believed that all of those were necessary and were going to be built.
Gavin: It’s just one situation where estimating…The whole point of it, was taken out of the team’s hand.
Paul: I’m just looking at the way we used to do things was that we tried to estimate in the ideal days or ideal weeks about how long something would take, or months even. We used to use a model. The COCOMO I think it was called.
You broke it down into chunks of work, but they weren’t particularly small chunks of work. Not compared to stories anyway. You gave them a complexity rating, and then you factored in other things in terms of…I can’t remember exactly now the COCOMO model, but it’s a…
[crosstalk]
Gavin: It’s easy for you to say.
Paul: That’s right. It’s easy for me to say, but essentially you were creating this precise number at the end of it which was all based on these values that you plucked out of the air to start with.
Kirstin: It’s the Constructive Cost Model.
Paul: That’s right, and we were using this in terms of building new software. This is the thing we keep saying over and over again. If you’re building the same thing you’ve built last year, then you’ve got a very good idea of how to build it.
All this evidence-based kind of approach to estimating in software would work if we were building the same thing that we built last year, but you don’t build the same things that we’ve built. We build new and innovative technology every time.
We use new and interesting technology in ways that we’re trying to make a point of difference so that we can, i.e. improve our business process or make a point of difference that we can sell and capitalize on. Software just doesn’t work well with evidence-based, rule-of-thumb type approaches.
We’ve moved to story points, and we’ve got much more of the relative story-sizing, and we’re looking at complexity, certainty, and all of those kinds of things and unknowns. We’re just saying gut instinct and relative to other stories.
To me, that kind just goes one step further with the no estimates, which is that the story sizing and the story approach is great at a small piece of index-card size piece of work. Then moving to no estimates just seems like not that much of an extra leap to me…
[crosstalk]
Gavin: My own personal feeling about this whole movement is that estimating is really, really useful.
Paul: To invoke a conversation.
Gavin: To invoke a conversation. It’s a useful tool to get that happening especially with new teams or teams that are new to Scrum, teams that haven’t really worked together. I think it’s a very useful tool for that. I think to throw a team in without estimating might be problematic if they are new to the project or…
[crosstalk]
Gavin: I think a team could very easy evolve, which has happened with your team. Evolve into that whole no estimating thing. I’ll be interested to see how a project would work if you just took estimating out of it from the outset.
Paul: I agree with you. I still feel that that approach, the user story approach and no estimating and Scrum as a framework, is an Agile instrumentation like a set of training wheels.
Once you understand the Agile principles and you’re living the Agile values and principles, then I think you can start to look at whether the team can decide whether you need to take some of these things off.
You just need to check in with the team whether they actually understand what the values and principles are of the work and what might happen if we stopped doing something like estimating or having retrospective meetings or having daily stand-ups.
Gavin: I suppose that that leaves just one issue or problem whatever word you want to use about no estimating if you choose to go down that path. It’s that it’s a hard sell to management, or in our place clients, because it’s very hard for them to do their release planning and to really get their heads around it. It’s a total mind shift.
Kirstin: If you were to talk to them about counting stories instead of as velocity rather than extra story points, I think that that’s basically the same thing if all of the stories are the same size.
Gavin: Yeah. Again, it’s having that buy-in from the top, I suppose, which is always, always really, really important. I think we really need a lot of trust there.
[crosstalk]
Kirstin: To obtain those, moving to this, obviously you have an established relationship with the product owner, hopefully, only see it than you which is maybe more tricky. It’s a high trust relationship already. That is part of the reason why it’s a mature team that’s going to be thinking about this, right.
Paul: I agree with you entirely. It should be a mature team that’s looking at this. These are mature teams that are moving to this no estimates approach. Estimates teach a couple of things, i.e., the focus is on delivering value and breaking stories and using the INVEST model in this one.
I think those are really good approaches to go through it at the beginning of this. We say this again and again that Scrum feels like the training wheels and the approach is seeing this as a set of training wheels.
I think the maturity thing is there’s a number of ways of looking at it. Some people call it Agile fluency.
It’s interesting that the team here that’s discussing the no estimates approach really is into this project. They know each other well. They know their product owners well even though one of them has changed.
Kirstin: Actually the team members have changed as well, not all of them. Certainly, two of them haven’t been on it for three years. Because it’s such a well-established team, bringing them in and getting them on board was a lot faster than it would have been with a new team.
Paul: That’s right. It’s a classic example of a value stream of work that has remained really effective because even though like you say teams, the team has probably completely changed since then.
Kirstin: Yeah. It’s completely different from how it started.
Paul: Yeah. The way that we integrate team members and the way that the team integrates team members whether the team is different, the team members with new team members, has worked really well.
Kirstin: Yeah. I mean it’s practically seamless except for that first couple of weeks and then they’re on their way, right.
Gavin: If anybody has any comments or anything about no estimating, you could give us a shout.
Kirstin: We’re talking to you, John.
Paul: It kind of segues nicely into mob programming and talking about the team. The mob programming approach, the great analogy that I’ve heard about this, is it’s like an ER or an emergency room.
If you’ve got something fairly minor that’s happening, you’re sitting in the emergency room for hours and then waiting for a doctor to see you.
As soon as someone comes in that is an absolute emergency and they have to deal with them straight away. You certainly get a very reasonably nice group of people gathering around.
Several doctors, several senior medical staff will be there discussing approaches and having that conversation backwards and forwards about what the best approach is would be to get this person as stable as possible or as quickly as possible.
It’s quite an analogy to mob programming except mob programming is the next level on from pair programming if you like where mob programming is where you have the whole team involved in solving a problem.
Kirstin: Hopefully, with a little less urgency than an emergency room.
Paul: Yeah.
Gavin: Mob programming is basically when you have an entire team around one computer. You have one person doing the…
Paul: The facilitating of the team if you’d like. That’s what they call it. They’re the person who’s typing in the code or whatever they’re doing. You have the whole team. This is a cross-functional team that we’re talking about. It would be BAs, UX testers, and developers all sitting there if that’s what you would…
Kirstin: Whatever the team is made up of.
Paul: …if that’s what your team is made up of. They all take turns. Basically, they’re working in a gang and then making comments on them.
Kirstin: This is just going back slightly to estimating. John has made a comment saying, “Our biggest problem with estimating has been in underestimating. We used a one, two, three, five-system. A five-point story once became a 20-point story over four sprints.”
Gavin: OK. Maybe you need some more cards there for a start.
Kirstin: Yeah [laughs] .
[crosstalk]
Gavin: You got stories that do obviously become a lot bigger. You need to re-estimate them. I wonder it would be…
Kirstin: That’s over four sprints. Wouldn’t it be more tempting to break that story down into simple stories so you can finish one and then move onto the next?
Gavin: I think that’d certainly be a good idea. I’d be interested to know why if people felt that. You’re saying that you’re working on a one, two, three, and a five-system.
Paul: Yeah.
Kirstin: Yeah. This is getting some people to pipe out when they think a story is underestimated. Maybe what needs to happen on helping members of the team to contribute during meetings? Not everyone feels the same confidence, but there are certainly ways of establishing safe…
[crosstalk]
Gavin: I think as a Scrum Master and stand-ups as well, you’re going to notice that the story is…While you’re going to know if there’s not a lot of progress being made in the story. That might be a good time to ask the team. “Hey, what’s the situation here?”
Kirstin: Should we revisit?
Paul: Recalibrate essentially, John, because obviously a story has to be one-third or one-half of your sprint duration maximum. You need to get two or three stories into your sprint at least.
If they got five as their maximum, then what we would be saying if they get a five if that was their maximum number they could assign a story. If they get a five, I would be asking them to say, “Well, a five is too big to fit into your sprint. How are we going to break the story down then because we need to…?”
[crosstalk]
Kirstin: Yeah. Kind of breaking down. Yeah. Because the scale is so small.
Paul: That’s right. You need to add a number like an 8 or a 13 at least or maybe a 20 or you need to get the team to start breaking stories down as soon as they get to a 5. At 5 essentially is that extra-large story and that means it should be in the sprint.
Kirstin: Because of the scale.
Gavin: Just a very basic thing of putting in like you’re saying the 8 and the 13 in there would at least give the team members the flexibility to say, “Well, this actually feels like a monstrous. I’m going to put that on a 13.”
[crosstalk]
Kirstin: You could still just work with 5 being the largest because even if you add an 8 or a 13, you still need to remember that an 8 or a 13 need to be broken down.
[crosstalk]
Kirstin: I think that’s the major point to remember that the larger story needs to be broken down, given your experience, recent experience, with the stories ending to have four sprints. I hope that helps.
Gavin: Mob programming that’s what it is. It’s interesting because that’s another…
Paul: It’s just extends the ideas of pair programming. It takes them even further as it involved the entire team and actually building the product.
The proponents of this sort of state is that you will get software delivered faster and with a much higher quality than you would have done using just a single programmer or a pair programmer. Because you’ve got the entire team who are responsible for delivering that software present and able to comment so that the testers will be making comments.
They might even take over the keyboards. One of the testers might even start testing the software as you go and so on. There’s lots of ping pong going on with the keyboard.
They talk about “pair programming ping ponging” in the sense that they developed a rites of test. They passed the keyboard over to the other developer who then writes the code that fulfills that test and then they write a test.
Then they pass it back to the other developer to write the code that fulfills that test and so on.
[crosstalk]
Kirstin: I’m looking for the potential problems with this approach being actually a skeptical person. Could it be too many people on a problem though too many opposing views? Is it your opinion that you can never have too many views when you’re approaching a problem?
Paul: If you got, for example, nine developers quite well, they will all have different ways of doing things. These guys were a Scrum team and that means we have to work on things as a group. They would have an agreed way of working. As they get to know each other, they will know each other’s…
[crosstalk]
Kirstin: Given that a Scrum team is five to nine people, you could potentially have nine people talking about this problem. I can see that sort of taking longer to resolve than if there were two or three people.
Gavin: I’ve never seen mob programming in practice.
Paul: There was a great video actually that we should tweet out or…
[crosstalk]
Paul: It’s a four-minute elapsed time video of eight hours of mob programming. It gives you a really good idea of what the five is like in terms of what they…They may have interaction and so on.
My argument would be, and I think this is the argument for mob programming, is that those discussions will happen. There’ll be a much longer feedback loop happening though as a result of the…
If you check some work in, and another developer spots a problem, or the tester spots a problem with it, down the line and you’ve got a lot longer time for that feedback to get back to you and for changes to be made effective. It’s about shortening those feedback loops as much as possible.
Kirstin: That would be interesting to see in practice.
Gavin: Yup. OK. That’s all we have time for today. We are going to try with The Board to limit our topics to one, possibly two, per week. We just feel it will help focus things a little bit.
If anybody has any topics that they’ll like to see and talk about, feel free to send them in to [email protected]. We’d really love to get some topics brought up by people outside of just us. Otherwise, we’ll see you in two weeks’ time.
Kirstin: Thanks. Thank you.
Paul: See you.
