By Rebecca Jones
In Episode 41 of The Board, we talk about:
Gavin: Hello. Welcome to episode 41 of “The Board.” I’m Gavin Coughlan, Agile Coach here at Boost. We are broadcasting live from the Boost Headquarters. Today we’re going to be talking about velocity and what it means to us.
If anybody’s watching, you can let us know what it means to you as well.
Jesse: Cool. Hi, and I’m Jesse. I’m another Agile Coach here at Boost.
Gavin: We’re both wearing the Agile Coach uniform of blue-checked shirts today. We’re going to talk about velocity, and what it means to us. This is something that comes up a lot for us. People ask us about velocity. We’ve seen velocity used well, I’d say, and we’ve also seen velocity misused as well. So it’s something I thought was worth discussing.
Jesse: Yeah.
Gavin: For me, it’s come up because recently I saw a company who have a velocity but the management project how many story points they need completed each quarter and they expect that amount of story points to be completed. If that’s not met, there are lots of difficult questions asked.
For me, that’s not the best use of a team’s velocity. For me, a team’s velocity is for the team itself, but taken out of that context, it loses it’s value and it’s just putting the team under undue pressure. If you ask the team if said to the team we need 20 points this sprint and they’ve only been doing 12 points, that’s their average velocity, well then, they’re going to whether it’s conscious or unconscious, they’re going to gain the system a little bit and start estimating.
Jesse: Yeah, overestimating stories to get that velocity up.
Gavin: Yeah, exactly.
Jesse: I think, should we take a step back quickly and just explain what Velocity is, I suppose, just for anyone who doesn’t know what we’re talking about?
Gavin: That’s probably an excellent idea. Actually, I’m making a few assumptions there.
Jesse: Velocity, the way we calculate that is taking an average of the points that a team delivers and sprints. If your team, over five sprints, had managed to deliver 50 points, the velocity would be 10 points a sprint, whether they had managed.
The actual spread numbers may not reflect that. They may have delivered five points in one sprint and 20 points in the next, but we look at the average over time.
I think your point there about management imposing a sort of a goal for the team of an unreasonable amount of points is something we see quite a bit. Your team might be tracking well nicely, tracking along at sort of 15 points a sprint.
Then all of a sudden, they’re like, “OK, well, you guys, just work harder and we’ll just get 20 points done.” That often results in sort of all kinds of issues and never, you never reach a goal of 20 points, and often you fall well short.
I think that’s interesting. Their people sort of misuse it rather than, yeah.
Gavin: Yeah, and I’ve also seen situations where if a team has a velocity of, say, 15 points. In our situation, we’ll have a client and the client will say, “Well, the team’s getting through 15 points per sprint and we’re spending roughly this much per sprint, so therefore, each point equals that amount of money.” Then they’ll project how many points the team might get through in the next six months, based on their velocity. They’ll use that to, you’ll come up with a budget.
Which is fine in some ways, but also, if that’s, if they’re going to hold to that and stick firm to that, that’s problematic. Because it doesn’t, a point shouldn’t be equated to time or money, explicitly, I don’t feel.
Jesse: No, and I think, again, it comes into this, back to sort of those principles of, it’s the team managing their workload. Points are really for the team to decide how much if is involved in developing a certain feature.
It’s not about giving the product owner some sense of, “This feature is going to cost me $1,000 or $10,000.” Yes, they can use that to points to estimate that kind of thing. But it’s not a tool, I don’t think, to be used to hold the team to account.
Gavin: Well, what do you think velocity is useful for?
Jesse: Well, so, I read an interesting blog from Mike Cohen recently talking about story points from the team’s point of view. Saying that a point is not about how many hours something will take.
Using the example of two people going for a run. If you and I met at a trail and you say, “All right, this trail’s going to take me half an hour to run.”
I say, “OK, well, this trail’s going to take me an hour to run.” We can sit and argue who’s right forever, but actually, we’re both right. You’re a better runner than I am, it’s going to take you half an hour.
Gavin: I am a better runner.
Jesse: I’m not a great runner, [chuckles] it’s going to take me an hour. What we should be doing and where story points come in is talking about distance. We can both say, “All right. This trail is 1.5 case long.” Both of us know how much is required to complete the trail.
Maybe you’re going to take half an hour. You’re a more experienced developer. I’m not an experienced developer so it’s going to take me longer. But the story points give us a way of having a useful conversation about work and how much effort is required.
Gavin: When you’re estimating stories, as with many things in Agile, the best thing to come out of it is the conversation that’s had around it. I know I’ve mentioned this before but to just to go over quickly again, if somebody estimates something, says “This is a size eight in terms of complexity and effort.” Then, somebody says, “It’s a size three.” Then, obviously, a bit of disparity there.
We’re just getting some comments here in this slightly, awkwardly placed laptop. Nathan Donaldson who’s the owner of Boost. “Actually, my money is on Jesse.”
Jesse: [chuckles]
Gavin: I think, that’s in terms of our running skills. I don’t know what made you think that. Anyways…
[crosstalk]
Jesse: …We’ll have to see.
Gavin: We’ll have a go after this. As long as it’s not larger or longer than 20 yards because I get quite tired quite fast.
Jesse: You’ve been boot camping so you should be. [chuckles]
Gavin: Anyway, that’s going off point slightly. If two team members size something that has large disparity in size, then, the conversation that comes out of that is really, for me, the valuable part because you find out if somebody has completely different ideas. If they know something that their team member doesn’t know vice versa.
Then, you have conversation. Hopefully, you’ll get to some consensus at that point. That’s one sizing. It’s really fantastic thing.
I had a team recently. This is a two person team because it’s a smallish project. We have a designer and we have a developer. It’s for a mobile app. They were some sizing stories.
Then, at some point, throughout the project, the developer said to me, “We’re not getting much value out of estimating stories here because Mike’s estimating from the designer’s point of view, and I’m estimating from a developer’s point of view. Really we just concede to the other person, whether it’s design-heavy story or development-heavy story.”
That made a lot of sense to me and had a discussion about what impacts they thought we’ll have if they dropped estimating [inaudible 8:36] . Would there be any negative impacts? They both seem to agree with it, so we didn’t estimate the next sprint to see how that would affect things.
They’ve been working on Scrum teams for a long time so they have a good sense when the story is too big and when this be broken down without actually estimating it. That’s fine.
That’s one project were we’ve just done away with it estimating. We still talk about the stories as per planning. We still talk about what needs to be done but we have done away with the planning [inaudible 9:03] that we actually used to use.
Jesse: When during sprint planning, when they’re laying out the stories, do they just stop their gut feel?
Gavin: It’s absolutely gut feel. It’s actually worked out remarkably accurately. We’re going stories one by one. Then, obviously, at each point we say, “We can do this and this the next two weeks. Let’s start. Let’s stop.”
They can compare it to the work from the previous sprint but they’re not looking at the story points themselves. It has worked out remarkably well.
I just feel that estimating in that two persons team might have been unnecessary overhead. Perhaps, estimating isn’t always necessary in a Scrum team. Then, again, I find in larger teams, it’s a really valuable exercise.
Jesse: I was just going to say so often, as a Scrum Master, I might use the team’s velocity just to help them out during the sprint planning. Especially with new teams where maybe I can sort of have a sense that it looks like they’re over committing.
Just to kind of coach them and say, “How do you guys feel about this? Do you realize last sprint where your velocity has been 10 points and the sprint you’re committing to 25? Are you happy with that? Is that something you think you can achieve?
Gavin: Velocity is a tool for sprint planning and just a gauge, a guide for the team really.
Jesse: I think, especially with new teams, it can be quite useful to talk to them and use their velocity to get an idea of sort of an average that the team seems to be quite happy with, and sometimes coaching them and saying, “Well, do you think this was difficult as the last sprint or not as challenging?”
I wouldn’t want the team to start committing purely based on their velocity, but I find it has been very useful for teams to use as a guide. Maybe if they’ve got a couple of complex stories, they might choose to estimate slightly below their velocity because they aren’t sure about those stories. If the backlog is full of really easy, small, well-defined stories, they might choose to go over.
Gavin: In that situation, it’s really a fantastic team, too?
Jesse: Yeah.
Gavin: Then we have an interesting question here from Nathan Donaldson, “How does a business owner know whether the team is working hard enough?” That’s a good question. My first point is, does velocity help a business owner know if a team is working hard enough? Does that really have any bearing on how hard the team is working?
Like we mentioned earlier, a team could easily game the system subconsciously or unconsciously to make it look like they’re working harder. I suppose, based on that question, you get into the idea of what metrics do you actually use within Scrum and within Agile to look at how hard the team was working, or how productive the team is, or whatever you want to actually call it.
There’s lots of conversations about it. I won’t go too deep into metrics because we’ve talked about it before. It’s just not fascinating to talk about it for me…
Jesse: [laughs]
Gavin: Because people put too much weight on metrics, I feel, at times, whether it’s lines of code written. We’ve talked about that before. That’s ludicrous measure.
For example, I saw an Agile cartoon today. It was a business owner goes over to team member and says, “How many lines of code did you write?” They said, “I wrote five lines of code.” They said, “That’s not enough.” They said, “Well, if it’s a cure for cancer, still, it doesn’t meet our metrics…”
[laughter]
Gavin: “Of lines of code written.” It’s not really the output, in terms of lines of code, that you’re looking for. It’s the value that the team has actually created within the sprint.
Jesse: Again, what we tend to see in Agile teams is if you empower the team to manage their work, and estimated how much can be achieved, and engage them, you don’t get into that situation where people doing a job, if they enjoy what they’re doing and working in a team that they enjoy, they don’t spend their time trying to slack off and do other things. They’re truly invested in the product and delivering value to a business owner. In teams that we’ve worked with that worked with Agile, it has not been a problem that we’ve encountered.
[crosstalk]
Gavin: No. The more metrics you throw at an Agile team, the more you crush the soul of Agile, in a way.
A lot of Agile has to do with trust, in many ways, which makes it difficult to talk to, say, people who are new to Agile about it. If you do work with the business owner daily, which you should be doing, them they will know that the team is actually working hard, and the team is proving value, hopefully, each and every day.
They’ll also have an awareness from going to stand-ups and just talking to the team throughout the day when things are going off track a little bit, or if they start to go off track, hopefully, they’ll know straight away so that can be put back on track really, really quickly.
Jesse: I think also in Agile teams you find, because a team has committed to delivering some work, if there is one member of a team that their team is underperforming or slacking off, often other team members will hold them to account rather than a business owner having to step in and, I suppose, crack the whip.
It does actually brings that discussion around value — a business owner getting value does raise an interesting point that we’ve sort of been looking at recently with our teams around velocity — and whether you include bug fixes in your velocity or sort of maintenance-type work that doesn’t actually deliver new business value.
It’s an interesting thing that a team can look at on a case-by-case basis. The premise of it is that Scrum is all about delivering value, and so your velocity should be a measure or could be a measure of the new value that you deliver to a product every sprint.
For example, if you had a sprint that had 10 points of work, and 8 points of that was bug fixing, the total points would be 2 points that would contribute to your velocity.
Gavin: At the moment, the teams that you’re Scrum master for, are they including their bug fixes in their velocity?
Jesse: They are. I suppose what their velocity represents is the amount of work they get through in a sprint, not the amount of value that they deliver in a sprint.
It’s a team-by-team decision, but it’s an interesting one to discuss with your teams and the product owner as well because if you’re at a new product that you’re developing, and delivering value is the most important thing, maybe having that velocity that measures value would be more useful.
Gavin: That’s interesting because obviously we’re talking about measuring value and delivering value, and that’s a bit of an airy-fairy term in lots of ways. How do you actually measure that? That’s possibly a good way to try to at least get close to.
Jesse: It would be something none of the teams that I’m working with, I suppose, have wanted to use that way, and that’s the product owners as well, because they didn’t feel like that measure was useful to them. It would be really interesting to try it with a team and see how that changes and changes the way that they work. Definitely something to try.
Gavin: I’ve seen people would rather than count story points, they count the amount of stories that are actually being completed within the sprint, because each story itself, if written correctly, and done correctly, and meeting the invest model, is going to be creating better value. If you get through 10 stories in a sprint, that’s a weight countered.
Obviously, stories are going to be of a wide variety of sizes, but, over a period of time, you’ll get an average amount of stories that you might expect to get through in the sprint length.
Jesse: I suppose another thing contributing to velocity, that teams often sort of talk to the Scrum master about, is when you have a story that’s not completed at the end of the sprint, and maybe it’s eight points or something, and they’ve done 90 percent of the work, a lot of teams say, “Oh, well, can we just…Do we include that eight points in that sprint to sort of maintain our velocity and bring a small one-point story across, or how do we manage that?”
I suppose, personally, in the teams that I run, we like to just bring the whole story across, and so the eight points carries the next sprint. One sprint has very low points completed, but the next one will have lots. Your velocity, because it’s an average, it balances out over time.
Gavin Coughlan: Personally, I feel that’s a good way to do it. You shouldn’t put any of those points towards the sprint if it’s not completed because then you haven’t delivered any of that value there. I’ve got another question here from Tony O’Halloran. We already answered it, so just, “Hey, Tony.”
Jesse: [laughs]
Gavin: I was in a sprint planning recently, yesterday, two days ago, where we reached a point were the team said, “That’s all we can actually commit to in this sprint.”
The designer stepped in and said, “Well, actually I think I haven’t got that much work. If we talked to the project owner, would I be able to take some of the stories lower down in the product backlog and bring those in, because they’re smaller stories and I feel I’ll be able to complete these on my own in the sprint, even tough they’re of lesser priority?”
The product owner though, “Yeah, OK. That’s a good idea. Even though they are of lesser priority, we can’t get any of the stories above it done in this sprint, so we’ll take them in” and thought that was pretty interesting to watch happen. That was also based just completely off gut felling, without using the actual points system and all.
Jesse: I suppose another good use of velocity is trying to see, “Well, you know, maybe we haven’t got the capacity to take on this really big story, but we feel, you know, that there is space in this sprint for more work, and can we bring in something smaller?” Having that discussion with the product owner about those sort of things is always really useful.
Gavin: It’s interesting. I been reading obviously about velocity and this sort of stuff. The more that I work with Scrum teams, the more I feel when the best…To sort of go back to that earlier question about the business owner and, “Are the team working hard enough?”, measuring team happiness sounds like a very happy-clappy sort of a thing to do. In many ways, it might be.
But any time that a team isn’t delivering what they feel they can deliver, if not delivering to the best of their abilities, they’re just not happy. You can sense it usually if you’re fully involved with that team.
You can usually get a feeling for if they’re not happy, and if the product owner is not happy, and if they are producing at the best of their ability, if they’re really a self-organized and high-performing team there that really loves coming to work, and the mood is really fantastic all the time. Measuring team happiness might be the most valuable metric.
I’ll be willing to throw every other metric out the window and just have that one, actually.
Jesse: That’s a really good point. When you’ve got a happy team, then, generally, the product owner is happy as well, and they do deliver consistently. That metric is probably far more valuable than velocity.
Gavin: What impacts do you think it would have, for example, on your biggest Scrum team at the moment? I don’t want to put you on the spot or anything, but what impacts do you think it would have if you remove velocity from that team altogether?
Jesse: I don’t think it would be a huge issue. The product owner would have a problem with it because they do use velocity as a planning tool in the short term to sort of gauge how much or where work fits and prioritize work.
For the team itself, I don’t think that they would feel like they’d lost a lot. They’ve been going out, as they’ve been an established team for months now. They’re quite happy with committing and don’t really use velocity as a tool to sort of check their commitment. They’d be quite happy to do away with it.
Gavin: That’s an interesting point that you brought up about the product owner. It would have an impact on the product owner because they use it for planning. That’s an excellent point, because it is very useful for release planning. That would have quite a detrimental effect to remove velocity in that situation. I suppose you have to gauge things on a case-by-case basis.
Just one answer. We have another question here. We have two questions. We’ll answer the first one. How do you measure and reflect happiness?
Jesse: I suppose there are a number of ways you can do it. You’d have to base that on your team. One thing that we’ve tried at Boost was, when you come in in the morning, just having three buckets and just dropping a ball. I can’t remember the exact measures. There was a happy face, a kind of…
Gavin: There was a meh face, a happy face, and a outright sad face.
Jesse: You’d come in the morning and drop your ball in wherever you were feeling. If you were stoked to come to work, you’d say, “Yup. I’m feeling happy.” Someone would take a tally, once everyone was in the office, of how many happy, meh, and sad faces there were.
Then leaving again, on your way out in the evening, you’d do the same thing. If you’d had a really terrible day, maybe you’d drop one in the sad face. We just kind of kept to running tally of those measures.
Gavin: I thought that was OK. I thought we made that a bit more complex than it needed to be. We’ve based that sort off the Niko-niko chart. The Niko-niko chart is a chart that you can use for measuring team happiness.
At the end of every day, you have this chart up on the wall, big visible chart. People put either a sad face or a happy face by their name in that calendar date and over a period of time. Then you can see where the team has been feeling happy, where the team hasn’t been feeling happy. That can point to a lot of things.
For example, if a team is really happy, but not delivering, and if you feel they’re not delivering, and they’re really happy, there’s obviously a problem there. Maybe people just don’t care about what they’re doing. Also, if they’re really sad, but delivery seems to be high, there’s something to investigate there.
It’s a really good way of seeing the team happiness over a period of time. It’s a very visual way. Usually, there’s going to be sad faces when there’s big problems, and happy faces when everything goes along really nicely. But you never know. You can get different information from that chart.
I thought the Niko-niko chart was a simplified version of what you described because it just asks people to do one thing per day. It’s not giving you three options, because that middle option “Oh, do I just feel OK?”, which is melancholic.
Jesse: [laughs]
Gavin: You want to make is a easy as [inaudible 27:11] possible to actually measure their happiness. If you haven’t looked at the Niko-niko chart, we’ll put a link under the live stream video at the end, as well. I think it’s a really good way of measuring happiness. Nathan also asked, “Did the balls and buckets stick?” No. It didn’t.
Jesse: Nope. [laughs]
Gavin: That’s because we made it too complicated. That’s something that we need to revisit. I feel — who knows, we’ll experiment — if we simplify it, it might be more successful.
Jesse: Absolutely.
[crosstalk]
Gavin: Make it mandatory.
Jesse: Mandatory?
[laughter]
Jesse: The other thing that you can do, I suppose, as a Scrum master, if you feel that happiness is a problem, and you just want to explore that, is maybe run a few retrospectives consecutively and activities within the retrospective that give you an idea of what the team is feeling.
Mood lines is quite a good one for that. I recently had a sprint where we had a deadline, and things got a bit stressful. We did mood lines in the retrospective.
[crosstalk]
Gavin: I saw them.
Jesse: You could see everyone was really happy as a project, that the team is very happy. But as it went along, there was this massive dip around the release point. Then we came back up after the release. Mood lines is a great one.
Gavin: We ran that recently, you and I, for an external team. It was the first time they’d ever done anything like that. It was over the course of six months. There was massive mood line, took up the whole wall.
It was fantastic. The amount of honesty that came of that was great. People heard points and feelings said from people that they never knew existed for the very first time. It was quite amazing to watch. Mood lines is a good one.
Jesse: You could even run that same exercise for three or four retrospectives.
Gavin: Just a mood line, just to quickly describe this for us. Say you have a board here. You’d have a horizontal axis which will be the times that it might be your sprint, so you might have week one or week two. Then, on your vertical here, you have a happy face up here and a sad face down here.
People will literally get a pen, and talk about their sprint, and draw a line along the timeline, and go down if they were feeling pretty bad, and they’d go up here if they were feeling good. You’d get sort of a graph of how they generally felt throughout the two weeks.
We’re getting close to the end of the show. We do have one more question from Tony. Let’s see. Nathan said, “How do you measure and reflect happiness?”, and Tony said, “And stop that measurement from becoming boring and ignore it?”
I suppose we already answered that, Tony, but that bucket system we had did become ignored. It’s just something that we want to revisit and look for a better way to do it because, obviously, if people aren’t using it, it’s just not an useful thing to have around.
Personally, I walked by that bucket of balls every morning. I saw that it wasn’t been used, and I found it actually slightly depressing to walk by it.
[laughter]
Gavin: It was actually detrimental in a way, I felt.
Jesse: To touch on Tony’s point, and Gavin’s team where they sort of did away with sizing, whatever metrics of measurement you’re using, if the team doesn’t find it useful, and it is boring and being ignored, it’s time to change it up.
If happiness worked for you, and your team find it useful, and you’re displaying it somewhere that’s visible to the whole team, and they take ownership of it, great. Obviously, for us at Boost, the buckets and measuring happiness didn’t resonate with the team, so stop doing it and move on to something else.
Gavin: That’s one of the key elements of Agile. It’s not resting on your laurels and not just being content with things the way they are. It’s always thinking of new ways to approach things and new ways to do things. I think that’s a challenge for a Scrum master around the team, really?
Jesse: Yeah. Absolutely.
Gavin: We’re just out of time in there. Thank you very much. That was episode 41. We’ve been through quite a few episodes. If anybody has any ideas or comments, please let us know. If you have something that you’d like us to discuss in the next episode of The Board, please let us know, as well. Thanks for watching today.
Jesse: Cheers.
