Editorial note: Transcribed and lightly diarized from audio for readability.
Introduction and Overview
Eric Naiburg: Good morning, good afternoon, good evening, depending on where you may be around the world. Thank you for joining today’s webinar, today’s webinar series really, Ask a Professional Scrum Trainer, and I want to welcome Yuval Yeret who’s joining us today. We’ll focus today’s webinar on improving flow in Scrum teams and how we can use Kanban practices with Scrum to help do that.
My name is Eric Naiburg and I’ll be your host today for the event.
So just briefly a little bit about this series. We try to run this series on a monthly basis to allow you, those of you learning Scrum, using Scrum, improving what you’re doing, to help learn more. Ask your questions of our professional Scrum trainers who are out there doing this on a daily basis.
Just briefly a little bit about Scrum.org. We provide training, we provide certification, and we also provide a whole lot of free assets to help you continue your learning. We’ll talk a little bit about learning paths at the end, learning paths for different roles in Scrum. Lots of webinars like this one, as well as blog articles, forums, and more.
And of course, we’re founded by and chaired by Ken Schwaber, the co-creator of Scrum.
We’ll let Yuval introduce himself. Yuval?
Yuval Yeret: Thank you, Eric. Good to be here on the webinar. So, I’ve been a PST for almost two years now. I came on board to the Scrum.org PSTs and the stewards team through the Kanban path. Basically, as we’ll discuss today, helping bridge the worlds of Kanban and Scrum, and that’s something that I’ve been doing for a long while, basically ever since I started to practice Scrum and Kanban back in 2006-2007.
And I’m excited about this new direction that we’re leading at Scrum.org.
Eric Naiburg: Great, thanks, Yuval. And if we can just go to the next slide.
So, just some quick guidelines. Your microphones are muted, but please ask your questions. You can see here on the right side the panel where you can ask those questions. Just send those in, and we will begin taking them right away. So without further ado, let’s have a look at what we’ve got so far, Yuval.
So the first question, since you’re one of the stewards for the Professional Scrum with Kanban class and have spent a lot of time both working in Kanban and Scrum, can you talk a little bit about what’s different between Professional Scrum with Kanban and the Kanban method?
Yuval Yeret: Yeah, that’s a common question we get in classes or when having a chat about this on social forums. So, a lot of people are familiar with the Kanban Method, or even when they say Kanban, they mean the Kanban Method. That’s an approach for evolutionary change created by David Anderson, documented in the Kanban “Blue Book”.
And that approach uses a Kanban system of visualizing flow, limiting work-in-progress, making your policies explicit, but it uses them within a very specific context of assuming that you’re working with an existing system that has flow problems. You’re not going to make dramatic changes; you’re going to take on the initiative to pursue evolutionary change for that system.
When we’re looking at Professional Scrum with Kanban, we are still using a similar Kanban system - visualizing the workflow, limiting work-in-progress, managing the work that is flowing and helping it flow - but we are also doing it within the context of a Scrum framework. And we are acknowledging that the goal isn’t to move away from Scrum.
The goal is to use Scrum according to the Scrum Guide and use the Kanban strategy to complement Scrum and improve the flow on Scrum teams. You might say that’s a nuance, but it’s also, for many people, it’s a major difference. Because when you talk to a lot of Kanban Method practitioners, when they’re working with Scrum teams, their goal - or not necessarily a goal, but they feel okay about moving away from Scrum while pursuing flow.
And we believe that there’s a lot of value in everything that Scrum brings, and we should be using both the empiricism of Scrum and the flow that Kanban brings together.
Eric Naiburg: Great. Thanks, Yuval. So we’ve got some more questions starting to come in here.
So, can you talk a little bit about the relationship between cycle time, SLEs, and sprint length?
Yuval Yeret: Yeah. So, cycle time - first of all, let’s define what do we mean by cycle time and SLE. Cycle time in our definition in Professional Scrum with Kanban, the Kanban Guide for Scrum Teams, we define cycle time to be the elapsed time between the moment we actually started work on an item and the moment that we finished it, the moment it got done.
Now, a team might have that simplistic version of cycle time for their PBIs, or a team might say, “You know what? We’re also interested in other cycle times, like from the moment we started to refine it to the moment that it’s actually released, not just part of a releasable increment.” But let’s stay with the simple definition of cycle time.
Let me say we’re using cycle time as from the moment we pull something from the sprint backlog and we start to work on it to the moment that we consider it done according to the team definition of done and part of a releasable increment.
Now, you might say, what’s the difference between that and the sprint length? Hopefully, there’s a difference. I mean, if we’re seeing that all of our PBIs start on the first day of the sprint and finish on the last day of the sprint, then probably we have a problem. We’re doing something that is closer to a waterfall or big batch within the sprint with a very high work-in-progress, and we’re not really creating small increments or a flow of small increments along the way in the sprint, which is what we’re striving for.
Another artifact of that sort of behavior might be that the last couple of days of the sprint are pretty tough, with a lot of risk that things would actually not fit into the sprint or would only be forced-fit into the sprint by reducing quality or taking on technical debt or working unsustainable hours.
That’s not what we want. This is what we call mechanical Scrum or believably bad Scrum - Scrum that follows all of the rules, but it’s not the Scrum that we want to see.
So what we want to see is cycle times that are actually shorter than the sprint length. I like, on average, with the teams that I work with, I like to see cycle times that are around half of the sprint length or even less. Some items would have a longer cycle time, but on average, most of them should be around half a sprint length.
So if you’re using, let’s say, a two-week sprint, you’d want to see a typical cycle time of a week from the moment you start something to the moment you finish it.
And that brings us to the SLE. What is an SLE? An SLE is the Service Level Expectation. That’s a Scrum team setting up that expectation for themselves. Basically, they might say, according to what I just described, “We would want the majority of our items to finish within a week.” So they would be very specific.
They would say, “Let’s say 85% of our PBIs should finish - we expect that 85% of our PBIs will finish within a 7-day cycle time.” And that means that around 15% of them might not, but 85% of them will.
How does the team come up with that sort of expectation? Initially, it might be based on past experience, what they want to achieve over time. What we want is for the team to actually measure their cycle times and validate that the SLE is connected to reality, and adjust the SLE based on reality, as well as in their retrospectives try to figure out, “Okay, what can we do to make our real numbers better fit what we want our SLE to be?” So maybe look at what are some of the key reasons items don’t finish within our SLE?
That’s something you could look at in your retrospectives and try to do something about it. Maybe it’s every time we need somebody from another team to do something for us, or we need to wait for approvals from legal or some answers from the design person that’s not on the team. Maybe that’s something to look at, something to maybe bring into the team or figure out a better process to do that.
You can be even more proactive than that. While you’re running the sprint, while items aren’t finished yet, you could say, “Okay, which items are on their way to finishing within our service level expectation?” So those items, are probably okay. We don’t need to spend too much energy on them. Let’s keep tracking them, but we don’t need to spend too much time on them, for example, in the Daily Scrum.
But items that are in the yellow or in the red look like they’re going to exceed the SLE. Those are exactly the items that you want to inspect and adapt on in your Daily Scrum. And that’s why during the sprint, we recommend teams look at their work item aging, which is basically a leading indicator towards what your cycle time might be.
Work item aging is simply how many days has this item been in progress, part of your WIP. And for example, if your SLE is 7 days with 85% confidence, items that are already on the board 6 days and you see that they’re only in the beginning stages of your workflow, that’s something that you should be worried about.
Items that have been 6 days and are in the last state in your workflow, just a couple of hours or a couple of small activities from finishing, maybe that’s less of a worry.
Eric Naiburg: Great. Thanks, Yuval.
Managing Flow and Testing Within Sprints
Eric Naiburg: So, we’ve got some more questions starting to come in here. Here’s a common question. I’m not sure this is totally tied to Scrum with Kanban, but it’s certainly talking about flow, however: Most of the teams in our organization deliver the Scrum goal and deploy the work code in dev environments.
Then UAT and SIT happen while the team is working on the next sprint or the next iteration. Is this a good practice, or should we have dev, UAT, SIT all happening during the sprint duration?
Yuval Yeret: Yeah, so it’s related and non-related. So, I would say whether it’s a good practice or not or whether it’s the right economic choice or not for your context is up to you to figure out. You know what’s the cost of running UAT and SIT testing as frequently as possible within each one of your PBIs and your sprints.
You know in your environment what’s the cost of that undone work, that lack of transparency that you miss by only doing your functional or dev team testing and getting late feedback from UAT and SIT environments.
I would say that typically teams that I work with over time realize that there’s a high price to that undone work. For example, in my earlier years - these days I’m only programming in Excel or in PowerPoint, at most on WordPress - but in my earlier years, I was working as a developer developing Linux kernel code for file systems.
And in those days, there was a huge difference to in how much it cost me and other people on the team to fix defects that we found in a simulator that we were running on a nightly or even throughout the day before we checked in code, because it was very easy to fix something in those situations. It was very, very hard, almost frightening, to try to figure out what’s going on with a performance problem that was only discovered in the final round of performance testing or in the performance testing that happened before release, because performance testing was deemed to be too expensive to run frequently.
This could basically turn a release that seemed healthy so far into a nightmare, and we all knew that. So over time, what we tried was to include performance testing as part of our simulators. And ever since 2004 is when I had that sort of situation, I believe that shifting left is always a good idea.
Shifting testing left into the process and increasing the strength of your definition of done during your sprint - not just at the end of the sprint, by the way, for each PBI try to get it to done throughout the sprint as early as possible and with as much transparency as possible - that’s always a good idea, but you need to look at the economics.
And if it’s too expensive to run these sort of tests throughout the sprint, maybe you should figure out what’s the right batch size, as well as work on what are some things that can enable you to shift things to the left: automate some things, create more environments, bring people that know how to do the UAT testing into your teams, bring more real-world data into your environment.
Now, the flow perspective on this is to measure not just the - I mean, if you decide, for example, that you’re only doing the SIT testing beyond the sprint, I would recommend you visualize that workflow and you manage the amount of work in progress, meaning the work that is not really, really done yet, that hasn’t been SIT or UAT tested yet.
Now, one way teams can do it is to have additional stages downstream in their workflow beyond their definition of done within the sprint increment and track items that have, reached done, but have not reached the point of really done or done-done, and track the cycle time to both of these layers. I definitely work with clients that have tracked this and used this to kind of make transparent the price of the amount of stuff that we’re not really finishing and make it visible and drive the discussion around that.
Another variant of this is to say, okay, we have a small PBI board which the team uses during the sprint and we have, let me call it the big rock, call it epics, features, whatever you want to call it, board that tracks both the upstream work of refining, figuring out which features or epics, big rocks
make sense in the product backlog, as well as downstream in the case that a lot of these downstream activities only happen at bigger batch sizes, like we accumulate a couple of things into a feature or an MMF or an epic and we do the SIT testing at that level. This epic board or feature board is a very common practice that people use Kanban and flow for to wrap around a Scrum sprint, especially when the team cannot really finish all of the work during the sprint.
Eric Naiburg: Great. Thanks, Yuval. So, yeah, I think you make some really good points there, which is bringing things into the sprint. I mean, we now see organizations who are releasing many, many, many times throughout a sprint. We’re not waiting till the end. And by being able to do that, we have to be able to test.
We have to bring all of those things into the sprint if we’re going to be releasing. And even how do I know what to work on the next sprint if we don’t know what we’ve delivered this sprint? How can the product owner prioritize it?
How can we review it with our stakeholders and make sure that we’re delivering the right things? Now, if we wait, we’re now possibly going off path the next sprint because we’re heading down the wrong path during the current sprint. So I think that’s some great feedback. Thank you.
Understanding Scrum with Kanban Dynamics
Eric Naiburg: Another question here, this comes right into probably your heart here: Is Scrum with Kanban just a Kanban board with fix-to-do items, like Scrum?
Yuval Yeret: So, is Scrum with Kanban just a Kanban board with fix-to-do items? I think you get back to Ayush’s question: what is Scrum with Kanban? It’s much more than just throwing a Kanban board, but…
Yeah. So, a common thing we show in the Professional Scrum with Kanban class is, we show a Kanban board. I mean, it starts with a Kanban board. The Kanban board probably has a lane on the left that is either sprint backlog or maybe product backlog if you start that early. It has some lanes that describe your process of working, could be as simple as in-progress and done, could have some different aspects like we’re implementing something, it’s in the queue before testing, we’re testing and fixing, we’re deploying, whatever your process is.
Is that Professional Scrum with Kanban? No, because, so far we haven’t done anything but visualize the way the work flows. It doesn’t really mean anything about the actual flow. It’s not really Professional Scrum with Kanban unless we start to limit the amount of work in progress. So, saying how many items can be in progress within each one of our steps in our workflow.
And I would say that it’s not really meaningful at that point either unless the WIP limit is meaningful.
So, for example, let me take food. I love ice cream, okay? Everybody at AgileSparks, the company that I work in, we all love ice cream. And without a limit, I’ll probably eat a lot of ice cream. So let’s say I limit myself. I say I only eat five ice creams a day. So with that limit, it’s not going to be a meaningful limit for my diet.
I’ll continue to expand and expand if I keep eating five ice creams a day. If I want to limit myself, a limit should actually be uncomfortable to me. Now, we have a slogan at AgileSparks that says, “Challenge your comfort zone.” Five ice creams a day will not challenge me; saying one ice cream a week, that would be more of a challenge.
Saying one ice cream a month would be a real challenge.
So we need to figure out what’s the right WIP limit that would challenge our comfort zone while being realistic and pragmatic for now. The next step is to manage the work that’s flowing. So use work item aging as I described before, use other metrics to lead you to look into the flow of work within and beyond your sprint.
And the last step is to inspect and adapt what’s going on with your workflow. Use these flow visualizations, the WIP limits, the lean metrics - use all of that information to improve the flow of your sprint, to improve the flow into your sprint, out of your sprint, to help you work as a Scrum team, to help you work with the organization, with your stakeholders to improve the flow of work with Scrum.
Now, in a way, maybe the answer is yes to that question, because it can be as simple as that. But once you start to have this mindset and this set of lean metrics and Kanban strategies and practices, there’s an impact to each one of the Scrum events, to each one of the Scrum artifacts, to each one of the Scrum roles that - I wouldn’t say it’s changed, I wouldn’t say that the Scrum Guide isn’t relevant anymore, but each one of those elements is impacted.
You have some other options in your toolbox for how to do things. You have new things to look at in your retrospective, new things to look at when you’re looking at your product backlog, in your sprint review and doing forecasting. You might use Monte Carlo forecasting and throughput rather than velocity.
You have new tools to use when doing sprint planning. You have a totally new perspective on the way a Daily Scrum should look like. Scrum masters have new tools for helping their teams improve. Product owners have new tools for forecasting and for managing the flow of work into the sprint.
So on one hand, it’s very simple and concise what is Professional Scrum with Kanban. On the other hand, it opens the world to a whole different set of complementary practices and patterns that people use and that we talk about in the PSK class.
Eric Naiburg: Great. Thanks, Yuval. So next question: Do we still use story points - or I’ll add to that, I guess, not just story points, but do we still do sizing in Scrum with Kanban, or do we just worry about WIP limits?
Yuval Yeret: That’s a great question. So, let’s start with story points. A lot of people aren’t aware of this, but if you’ll open the Scrum Guide and look for story points, you won’t find them there. Story points aren’t a part of Scrum; they’re a complementary practice. They’re a complementary practice that is used as a way to size your work going into the sprint and/or to size your work when doing release planning and forecasting and trying to figure out what makes sense and what is possible.
Those are the two possible uses, or let’s call them healthy uses, for story points and sizing as part of Scrum. Now you could continue to do that when you’re using Scrum with Kanban, but there’s another option.
The other option, and we’ve had great discussions about it in the trainers Slack channel yesterday, the other option is to say, “You know what? Let me take a look at something else.” So let, let’s continue. What we do with teams typically is we’ve used sizing and story points and we’ve calculated our velocity and we’ve been trying to forecast our sprints based on velocity.
That’s been working out, reasonably well for some teams, not working that well for other teams. There are many teams that actually spend way more time than they should be in their retrospectives on trying to figure out why their estimates are wrong instead of actually improving the way they work.
So let me look at something else. Let’s look at those team, the sprints that we’ve run that we’ve used story points for. Let’s look at just a count of how many items we finished in each one of those sprints. And for a lot of teams, when you chart out the, what we call the throughput, the amount of items that were finished in each one of those sprints, the graph is actually more stable than the story point velocity-based graph.
Which means that, spending time on sizing items isn’t helping our forecast. We would forecast better based on counting items.
So, for example, a team might be all over the place when it comes to velocity. Sometimes it’s 20, sometimes it’s 30, sometimes it’s 35, sometimes it’s 23. But for all of those sprints, in many cases, you’ll see that they’re between 8 to 10 items. 8 to 10 items every sprint. Now what I would do, if I was that team, is I would say, “Listen, the important piece is to right-size our items before we go into a sprint.
Just make sure they’re, at a reasonable size for our sprints, a size that would fit our service level expectation that we discussed earlier. And once we do that, I don’t care about the sizes. The sizes aren’t helping us. So let’s just right-size the items. All of the items that we accept into our sprint, we would consider them as, one unit, one item, and let’s just use that for our forecast for the sprint.”
Now when it comes to release planning and looking deeper into the product backlog when items aren’t that granular yet, it’s an open discussion what to do. One thing I like to do is to look at those big rocks or features, bigger PBIs that haven’t still been broken down and, try to guess or make a bet on how many items would that break down to.
Would that break down into 10 items, 20 items, 5 items? Does it look like an item that we’ve already done that got broken down into 8 items eventually? And in a way, that could be similar to story points, but we keep it just for deeper in the product backlog. Within the sprint, the only thing we care about is breaking work into its right size - that doesn’t mean same size, by the way.
It just means all of the work should fit within our service level expectation. And we know that there’s going to be some variance, and we know that some items aren’t going to fit our service level expectation. Some items are going to be bigger, some items are going to be small, but are still going to have a bigger cycle time and bigger problems because, there’s more dependency on other people within those items.
One of the things that we see is that there isn’t necessarily a strong correlation between the size of the item and the cycle time for that item. In a lot of cases, the delays that happen have more impact on our actual throughput and our cycle time than the actual size of the items.
There’s fascinating stuff once you start to look at your lean metrics as well, and most people, if they actually look at the lean metrics for their process, they would probably come up with similar conclusions. And that’s what we suggest: be empirical. Try both story points - if you’re using story points, continue to use that, start to use lean metrics as well, compare the two things, make the decision yourself based on the real data.
Don’t just listen to us and our experience with hundreds of teams.
Eric Naiburg: And it becomes important, too: let’s not get so stuck on velocity. Nothing drives me more insane than when people talk about velocity and hyper-velocity and increasing velocity. Anytime I’ve talked to people who say, “Oh, we’re comparing our teams based on velocity.” Well, guess what?
Those teams are going to cheat. Something that wasn’t a three is now a five; something that was a five is now an eight, because, “Well, we’re being measured on this.” And it’s not about delivering faster. I can deliver a lot of garbage faster; it’s about delivering value and making sure we’re delivering the right things and delivering what the stakeholders and the customers and the organization need.
And if we’re doing that, and when you hear Ken Schwaber, for example, talk about velocity and increased velocity, it’s not about delivering more; it’s actually delivering value faster and delivering the right things, because if we’re working within these boundaries and getting that feedback, there’s much more opportunity to deliver the right thing that the stakeholders need because I’m getting that feedback.
I’m not waiting six months to get the feedback; I’m doing it in two, three, four weeks. So, really, really…
Yuval Yeret: Yeah, let me double down on that a bit. Let me double down on that a bit because it highlights the connection between empiricism and flow.
So one of the things that we say in the Kanban Guide for Scrum Teams is what is empiricism? Empiricism - what is delivering faster, delivering value faster? It’s in an environment of uncertainty and complexity, we don’t know what value is, right?
We have some assumptions, some bets on what’s valuable. We need to validate those bets, and we need to deliver faster in order to validate those bets. How do we deliver faster? That’s measured by our feedback loop. Our feedback loop, from the moment we make a decision to the moment we build something and have real transparency on whether it’s working or not that enables us to inspect and adapt, there’s a name for that in flow: it’s called our cycle time, our real cycle time.
And by using flow, by limiting work in progress, by focusing on items that, haven’t finished yet, on work item aging, we focus on empiricism.
And if teams move away from measuring velocity and start to measure cycle time as their lead measure - not the only measure, and there’s a way to cheat with cycle time as well - but if they start to measure cycle times, then the default way to cheat, how do you cheat on cycle time?
How do you achieve faster cycle times? Well, either you improve your process or you break your work into smaller pieces. Now, if you’re able to break your work into smaller pieces that can still flow through the entire empiricism, transparency, inspection and adaptation feedback loop, all the better. That’s a cheat I’m, I’m glad to see teams do.
One danger, though, is if teams break work down into smaller pieces that aren’t really done when they complete the feedback loop, where it’s not releasable or it hasn’t been released and you cannot validate the real value, that’s a problematic cheat. So you need to measure cycle time and focus on cycle time, but also make sure that your workflow closes the feedback loop, closes the real feedback loop that includes validated learning about whether something is valuable.
So that’s the way I see flow and empiricism connect and complement each other.
Eric Naiburg: Awesome.
Team Dynamics and Overcommitment
Eric Naiburg: So, sticking with flow: How do you approach talking to the team, the development team really, about flow? Our teams couldn’t care less about good flow; they’re really kind of struggling with the agile mindset. So how would you approach that development team?
How do you get them to start thinking about flow and the importance and value of it?
Yuval Yeret: Well, I would use a soapbox like the one I just went on. That would be a good start. You know, one thing would be to basically ask them, okay, what’s - what are your goals, what are your problems, what are some things that you’re trying to do as a dev team that you’re struggling with right now?
So are you, do you see the need for empiricism? Do you have enough empiricism in your process? Do you see situations where you get feedback way too late and you pay the price for it? What are your pains?
And you could very quickly connect those pains of the context to lack of empiricism and lack of empiricism to long feedback loops and to the need to start to care about flow.
Another typical pattern is if people suffer from, multitasking and overutilization and not really being able to focus on their work. One of the Scrum values is focus. It’s rare that we let our teams actually focus on their work. In that sort of situation, limiting the amount of work in progress would be of huge help to the team, to the health of the team, to making the work of the team more sustainable.
So it’s really a matter of what is the context. I see the Kanban strategy as a tool that a Scrum practitioner, a Scrum master, an agile leader could use in their toolbox, but it’s not something that I would go and implement just because, there’s something you want to implement. You need to figure out, okay, what’s the problem, what’s the context, and look at, the patterns, the practices in that context and understand if they’re useful or not for you.
Hopefully, that’s helpful.
Eric Naiburg: Great. So, what do you think about Scrum for common PBIs and Kanban for production or support items? So I’m reading into what Jorge’s saying a little bit here, but essentially, using Scrum for some teams and Kanban for others.
Yuval Yeret: That’s certainly an option. A lot of organizations are doing it. The question to ask would be, would those teams that work on product development benefit from improved flow? And I can tell you from my experience, most of the teams that I worked on and worked with as a Scrum master and an agile coach and a Scrum trainer, most of those teams that leveraged Kanban were product development teams, because they struggled with flow, flow within the sprint and beyond the sprint.
Most of the operations teams that I see benefit from having some sort of structure and cadence and a clear product owner role that would help prioritize value and help them focus as well. Even teams that react throughout the sprint benefit a lot of times from having a sprint goal. Maybe they benefit even more from having a sprint goal.
Maybe that sprint goal is meeting a certain service level expectation, maybe it’s to try to find time to do something beyond reacting, maybe it’s to train each other while working on those production items. A lot of those teams could improve if they stop every couple of weeks and inspect and inspect and adapt their process.
So it’s easy to see the benefit of using the elements of Scrum in production environments and the elements of Kanban in product development. And that’s why when we talk about Professional Scrum with Kanban, what we’re asking is, why choose?
Why, leave so much benefit on the table? Why not benefit from Kanban when with Scrum when you’re doing product development or operations?
Eric Naiburg: Great. Thanks, Yuval. I think, just to echo that a little bit, we’re not saying, Scrum is a very simple framework and easy, it’s non-descriptive. Adding these practices and bringing them together so that we’re constantly reviewing, constantly looking at what we’re doing and improving it is an awesome thing, and I think bringing them together is a great way to help do that.
Here’s an interesting question. I think it kind of ties to this because it ties to some of what you’ve already said. Jeremy asks, “Would you prescribe exit criteria for the different states of work to replace the definition of done?”
Yuval Yeret: So, the answer is, yes, we recommend teams talk about criteria for specific lanes in their workflow or specific states in their workflow, so have clear, explicit agreement on what it means to do the work in each stage and when is it ready for the next stage.
I don’t see that as replacing the definition of done at the end of the increment. I see that as either complementing or breaking down that definition of done. So for a lot of teams, there would be the definition of done of the increment, and some of the elements from that definition of done would appear in earlier stages of the workflow.
So for example, if your definition of done includes we’ve reviewed, we’ve done a code review for this PBI and applied any recommendations, that would still be in your definition of done. It would also be something that you do as part of, let’s say, you have a coding stage in your workflow that would be part of the exit criteria from your coding stage, if that makes sense.
Eric Naiburg: Yeah, that’s great. And I think I think that’s important. The definition of done with it would bring those things together. It’s making sure that it goes beyond certainly just what is in development. It brings in things like security and other aspects to ensure that the way I talk about it is we’re releasing whole product or making whole product available.
So I think it’s important to make sure that we don’t that we don’t skimp on that. Thank you.
Lead Time, Cycle Time, and Managing Overcommitment
Eric Naiburg: So, next question: Should we count lead time when a story is ready, when it gets into the sprint? So, should lead time be part of that sizing or that planning?
Yuval Yeret: Yeah, so there are many versions and variants on what is cycle time, what is lead time. We stayed away from those discussions with the Kanban Guide for Scrum Teams; we just talk about cycle time. And as I mentioned before, the team could have multiple cycle times. They could have a cycle time for, their actual work, so from pulling from the sprint backlog and actually starting to work on an item until it’s done.
It’s also very interesting to look at the cycle time from the moment we start to refine a product backlog item, or from the moment it’s ready after refinement to the moment that it’s done in the sprint or released, or from the moment that we prioritize an item even before it was refined. There are different ways to look at cycle times.
I would say that the first two I would look at is the one within the sprint. The next one would be from the moment that we actually prioritize an item and decide to work on it to the moment that it’s valuable and validated in the field in production, which you might also call lead time.
I don’t see lead time as from the moment something is ready, because lead time also includes the amount of time it stays waiting in the queue from the moment you, let me say, you decided that you want to implement a feature, but it will now sit waiting until the team has capacity for it or until it’s the top priority.
It might sit there for a month or for two months. That’s typically considered part of your lead time. I hope that helps.
Eric Naiburg: Thanks, Yuval.
I think this next question kind of ties into this a little bit, especially the last one of the last parts that you said, which is, sitting until we have the time to do it. So, Mikko has a team that they’re working with that is constantly overcommitting. Do you have any recommendations or approaches that maybe would work to help the team stop taking more in, more work into the sprint backlog than they can handle?
They’re constantly arguing that there’s external pressures, this has to be done, if we don’t add it, we definitely won’t get it done, Little’s Law, and so on. Do you have any suggestions on how Mikko can better work with the team to understand, let’s just get started and not try to bring everything in and then, and then not achieve our goals?
Yuval Yeret: So one thing to remember is that the act of sprint planning, figuring out a sprint backlog, is an act that should be a form of limiting work in progress in and of itself. And that’s a realization that a lot of people get as part of the PSK class. And it sounds like it’s hard for this team to actually limit the amount of work that they’re pulling into the sprint.
Yeah, limiting WIP is hard. I struggle with just one ice cream a week. My body tells me it wants more ice cream.
And I think I would ask questions around, the role of the product owner in that environment and, are they letting the team focus, are we making transparent what’s the real capacity of that team? So I would, for example, take a look at throughput, the actual throughput of that team. And if we have real-world throughput data from that team or even velocity data from that team that shows, “Listen, here’s how much we took on and in real life over 10 sprints, this is how much we were able to accomplish.
And add to that how many hours we worked, what’s the level of sustainable pace that we’ve done over that time, how many, how much technical debt have we incurred throughout all that time,” take all of this information and create some sort of forecast. And it could be as simple as just looking at this data and drawing their conclusion, or it could be as advanced as putting all of this data into a Monte Carlo simulation and showing people, “Listen, with all of this information, and let’s correct for the fact that we’ve had unsustainable pace and technical
debt, assuming that we want - and that’s a big assumption, that’s a discussion this team should have with their stakeholders, the organization around them - assuming that we want to work in a sustainable pace, not taking on technical debt, not losing key people, and continuing to deliver value over time, assuming that we want to do that, there’s only 5% chance that we’ll be able to do more than 15 items the next sprint.
If you want to use story points, there’s only 5% chance that we’ll do more than 20 story points next sprint. Do we really want to take on 30 story points if that’s the situation? Do we really want to take 15 items if there’s only 5% chance that’s going to happen?”
Some organizations might say, “Yeah, we want the team to sign up to all that work because, if we don’t sign them up, if they don’t commit to all of that work, they will slack off during the sprint. The law of the gas that fills the container, they would find ways to fill the sprint and not be as effective.” Now an organization that feels that, to me, that’s a sign that there’s not enough trust, that there’s not enough engagement and motivation in the team.
And I would start to look at those aspects. I would start to look at what’s going on with the Scrum values around this team. Is there openness? Is there respect? Are we letting the team focus?
And those are tough questions to ask as, if I’m the Scrum master for this team and this organization, I have my work cut out for me. There’s a lot of work to do. And we’ve seen it way too often in the field. Many, many Scrum teams are in this sort of situation. They’re suffering from mechanical Scrum, and, they’re doing Scrum, but they’re not getting all of the benefits that they could.
And we expect, Professional Scrum Masters to know how to work with those situations, to know how to work with the team and the organization to remove these sort of impediments, to work on improving the culture.
And the flow metrics, the flow practices are another tool that those Scrum masters and Scrum practitioners and Scrum teams could use to help them on this journey. They could use a work in progress limit within the sprint to at least make sure, “Okay, we took on 15 items. At least let’s make sure that throughout the sprint, we’re not working on more than four of them.
We’ll try to get the 15 done four items at a time.” That’s something that could help us. Have more visibility towards what’s really going on with our flow, so that we’ll know better whether it’s possible or not, and we’ll have a better platform for having a discussion with our stakeholders and our organization about this.
Eric Naiburg: Awesome. Thank you, Yuval. I want to stick to our time box here, and we’re running pretty low on time. So, we do have a lot more questions, and Yuval will answer those questions via email and get back to you and hopefully be able to help everybody who has asked questions that we weren’t able to get to.
I see there’s a number of them here, and I apologize for that, but we do want to be conscious of your time that you’re taking today as well.
Conclusion and Resources
Eric Naiburg: So, just keep your learning going. If you’re a Scrum master, if you’re a product owner, or if you’re on a development team or in the leadership organization, we have learning paths for you. These are all free and available on the Scrum.org website. Go through these; they hopefully will help you learn and hopefully help you continue your education and your learning, as learning never ends.
They’re constantly updated, and we hope to keep providing these to you at certainly no cost. This is part of our mission, part of our mission to help improve how people work in the professionalism of delivering products to market.
Next slide.
So, with that, I want to say thank you. Thank you, Yuval, for taking the time today. Thank you, audience, for all the awesome, wonderful questions and taking the time out of your busy days as well. Keep the conversation going. Check out our forums and feel free to ask questions. We’ve got lots of people, both in our PST community as well as outside, who are constantly helping people learn and evolve.
Follow us on Twitter, LinkedIn, Facebook, and don’t forget, keep joining the Scrum Pulses and the different webinars that we’re doing, and read our blog.
With that, thank you again. Thank you, Yuval, and have a great day, everyone.
Yuval Yeret: Have a great day. Bye-bye.
Eric Naiburg: Bye-bye.