Welcome to the scrum sessions podcast I am q here in Dallas and I’m carry on based in Berlin welcome back to the scrum sessions podcast yes and uh this is the first one for 2023 and uh Welcome to the New Year and welcome to the podcast happy New Year so my friend what should we talk about today well you talked about capacity planning that it drives you off the wall because people are doing it in really interesting ways I have to say I’m really curious to hear what you have to report on so let’s take that topic yeah I think it’s a great topic you know and uh oh boy I it’s one of those topics I get passionate about one of the many topics I get passionate about right I have about 534 pet peeves that I can count that’s one of them right but you see I think people actually complicated I think people complicate a lot when they when they go plan for a Sprint and I’m not gonna go into release planning and Etc because I want this to be a separate podcast there’s a lot more to cover this so let’s talk only single team and planning for a Sprint right and in the past we talked about backlog refinement and how important is to do refinement and have refinement really nail down because if your jewelry refinement right your plan is going to be really easy right and I tell my teams all the time that and in the beginning they don’t believe but then they eventually they do but when I get a team that I didn’t coach from the beginning I just basically parachuting there you know they don’t know me I I I’m often surprised how they how they get to complicate stuff I had oil back one scrum master who had this elaborate Excel spreadsheet to calculate capacity right it was down pretty much to the minute and I looked to the person I said what are you trying to accomplish with this not to mention that oftentimes they spent an hour discussing how they could squeeze another two hours of work inside of a Sprint right I mean you and I know this stuff’s not gonna work and it’s funny how people complicate capacity don’t you agree with me or it’s just me who’s seeing that I’ve seen it as well and I think it’s the illusion of control right just because it’s manifested there in the Excel sheet that person thinks it’s actually going to happen in the real world and we know it doesn’t yep it doesn’t even come close and it’s funny because capacity should be very simple right let’s assume that nobody’s traveling there’s no holidays there’s nothing right so I basically tell my teams okay you have for the backlog refinement it’s all it’s all in order right most important to the least important we we went through all this stuff we split them we made them small they’re about all the same size and Etc right so it should be a simple thing item number one can we do that on the Sprint yeah good number two can we do that in a Sprint yeah good number three can we do that on the Sprint good until we say hey I don’t think we can do more right and then of course there is everybody always over commits I used to do that when I was writing code for a living we always over commit so that’s where the scrum Master should be careful that people don’t pull more stuff that they can handle but you as a team as part of a team you have a pretty good idea if something fits or not especially if they are about the same size right or near the same size and I always tell my team just count them okay how many you guys normally do on a Sprint I don’t know 10 okay so let’s pull 10 of them right assuming we have full capacity and all that stuff so I don’t see the point of spreadsheets and all these complication stuff but I don’t know how do you teach your teams how do you coach your teams into doing that first of all I want to just explain something to viewers that I’m for those that are listening I just uh picked up a stack of Post-its and started writing some stuff down because some kaizens came to my mind right so I was thinking okay maybe we can change this during the podcast and for all of you scrum Masters out there at least probably for all strong practitioners always write down your cousins immediately when they come to you because otherwise you’re going to forget about them so um how do I do it you’re going to be surprised that I’m even more relaxed right because you were just going through the process you start at the top of the backlog of the product backlog during Sprint planning and then you go down right and I think you can actually do it without any estimation and you can do it without any velocity right as long as you have an understanding of what’s in the product backlog right if you have never refined it of course you’re gonna fail but let’s assume velocity and estimations didn’t exist right what would you do you would start at the top and you would ask team so now that we’ve refined this we’ve talked about this we have just checked in that nothing has changed and we still have a good understanding of it do you think you can do it in the Sprint and for the first story they’re going to say yes right hopefully because if they can’t even do the first story you’re gonna have yeah it’s one right but so then you go to the second one and at some point of time they’re going to say this is going to be a little bit tricky right and then you’ve got to be very careful and I always say stop there immediately um and even don’t take that one borderline story in just take in as little as is feasible and then once they’re done early they’ll they’ll pull in more anyway right and then I’m good with that I don’t actually need the velocity and the estimations per se they’re very helpful and I’m not telling you don’t use velocity don’t use the estimations but I say I could do it without it right so if you can do it without it why do we even have them well because they’re super helpful right because if you have a measure of how large is this item going to be that you’ve decided on before and this is much more concrete much more efficient to to do the planning instead of like having just this broad feeling right where you’re like oh yeah we think we can do it so absolutely have them but you know if push comes to shelf you could do it without them and oh I I yeah yeah let me finish this because you know like when you started this this guy with a crazy Excel sheet he’s coming from the total opposite end where I’m coming from right I’m not coming from this extreme where I have like the minutes planned out I’m coming from I’m just asking them if they can do it right which is they tell the other extreme and then I move a little bit off it because they are super helpful to use and so for me this other extreme is really that it’s the other extreme because it’s it’s in the end it’s waste that person is spending a lot of time on an elaborate model right trying to um reflect reality when we all know this is not going to work and if I saw this I would have the immediate suspicion that that person might have been a classical project manager in the past right where they have this illusion of controlling uh evuka world and um trying to put everything into some sheets or plants that we know won’t uh won’t uh reflect reality after a second and so I’m coming from the total opposite end and I’m so I’m totally with you I don’t think it makes any sense to put all this work in its waste you start off very simple use velocity use estimations as a tool and then off you go honestly should tell the truth I don’t even use the word velocity right I use the concept of historical data how much stuff we normally do right the reason I don’t like to use the word velocity is well you know right it gets weaponized it becomes a Target becomes an obsession and that’s not the point the whole point of historical data whatever you call it is to give you an indication of how much stuff you can safely bring in right and do you know there is always a variability there’s a stuff that you don’t know but you have a pretty good idea of that the moment you weaponize that tank and becomes a Target oh it’s 20 so we have to do 20. right or oh we have been doing 20 for six months we have to do 30 now you know every time you set those numbers those are crazy things and they don’t work all they do is they stress people out and honestly I rather have people pick up less than the historical data and uh set up a Sprint goal with that right figure out what your outcome or doing those things is going to be and you’re probably going to finish early anyway right and if you finish early you can always bring stuff in right and that stuff in it’s going to have additional outcomes so I think people get a bit too
I don’t know what the right word is but sort of a involved in this number dance on Etc and they complicate stuff I’ll tell you something else another team I had they had one person who was gonna get half a day off to do some stuff I forgot what it was and they are like okay so if one person takes half a day off we’re gonna lose capacity so how how much capacity You’re Gonna Lose and they start discussing this they’re trying to come up oh uh they were using story points another thing don’t let me start doing that right and they were Thai oh that’s probably three points that they’re gonna lose or no no it’s true no it’s not three it’s true no it’s two it’s three uh they spent I don’t know more than an hour discussing that I said guys why are you doing that why are you doing that it’s not even significant that’s a negligible amount of potential loss in the end is not even that right and I think people get hung up on a we have to stuff every single available menu to the Sprint with stuff to do that’s being busy that’s not being productive yeah absolutely and so I do like velocity but it totally de-emphasize it right so I want to have it there I also use the term but I don’t put any weight on it and I see I think something similar that you’re seeing is that sometimes you know scrum Masters are really nervous and they come and say the velocity didn’t go up or we had a dip and it’s like I don’t care so first of all that was probably a reason right maybe it was the soccer World Championship that was happening the moon phase wasn’t right there’s always some stuff that influences that and what I want to see is over time I want to see an upward Trend I don’t care about the fluctuate fluctuations that are going to be normal and also and I know you’re gonna jump on this I don’t care about the points in the end I care about the impact that was achieved with the points right and Q2 Q oh to Michael I mean and I told people thousands of times listen I’ve been a product owner once and a product manager once right and I had actually to bring a large product to market right if I scrum team came to me during the Sprint review and some did this oh this is our burn down chart and this is how many story points we did I looked and then I said why are you showing me this stuff it means absolutely nothing to me what I want to know is what did you guys create and uh what impact that’s gonna have to my customer if that’s 50 story points or 500 I couldn’t care less
what matters to me is the outcome of what you’re delivering and I I think people lose track of this we are I’m not interested in story points so I’m interested is what can I bring in the Sprint and if I complete all those things that I brought to the Sprint what is the outcome for me that’s what I care yeah if it’s 50 points or 500 I couldn’t care less so I I kind of get a feeling right now that maybe we should give people a little bit more context because if you think of shoe Hari we are kind of like on the higher level talking right now so if you’re a scrum Master you’ve just taken your um your scrum master class right your registered scrum Master now and you’re just starting off and you hear us say that please don’t take this meaning as meaning yeah you don’t need to calculate the velocity you don’t need to do estimation so please do all of that do all the basics what we’re saying is the following um please don’t waste your energy on having meaningless discussions for an hour uh trying to figure out what half a day difference of one person means please don’t waste your time on keeping elaborate Excel sheets that don’t reflect reality and what we’re saying is that on a more advanced level there’s actually like a little bit more to it right but if you’re a beginner if you’re at the shoe level please just follow this along but as you progress on your journey you will start to feel some things right you will see that okay in two sprints you had the same velocity but one Sprint didn’t really deliver anything of value and one Sprint you know you just had those features that really made the difference in the market right and this is kind of what we’re talking about more high level more product owner view is of course we are preferring the second Sprint right because as the product owner I care about impact on the market yes I care about the velocity as well it’s good that this drum Master is keeping track of it and everything is going according to plan but in the end really in the end we care about impact because this is making the difference and not let’s say
I’m thinking of empty calories right like some velocity points that don’t really mean anything no I you made good points right I mean I have nothing against the concept of velocity like I said historical data it’s important to give us an idea of how well we’re going right and as a matter of fact I had a I had a situation where we found a plug-in for azure devops simulation right and if you’re not familiar with Monte Carlo simulation it’s basically a bell-shaped curve it’s a normal curve right and your EU input historical data in there which can be done automatically obviously right and in using that it gives you a pretty good approximation how you’re gonna trend and I think it’s actually much better than any other method because you have the historical data and you have the actual data for that Sprint and you can see how you’re trending during the Sprint is going to affect long term right so if you’re trending great okay good if you’re not training so well hey guys we need to get together do a return figure out why what’s not working here right and any good scrum Master should be doing that yeah but I prefer Monte Carlo simulation to a bunch of other things that people do that are way too complicated and honestly don’t don’t buy me anything but again I’m not against velocity I use historical data all the time as an indication right as a trend because as a product owner as a product manager I also when I have a clue when the whole thing is going to get out of the the furnace you know and be molded into a product and and get out of the door right but for my perspective when I’m on a Sprint review I wanna know what people did and how that benefits my customer at the end that’s what I meant I don’t care if it’s 50 or 500 yeah I really don’t I care if it’s 50 or 500 from the sense that I wanna I’m gonna go on my Monte Carlo simulation there and see how the trends are going yeah I’m not even preoccupied with the numbers I’m preoccupied with the data they put in there how that is affecting how we’re we’re going to deliver this but more important to me is what are we delivering every Sprint that brings benefit to my customer yeah and I think this is a really good point and so again talking to the beginner scrum Masters if you’re a product owner isn’t much more experienced than you this is actually something to look out for right so um most likely they’re not gonna have this Keen sense that Q is showing here right like really have that focus on impact and so this is something you should look out for right get the basics right have the Velocity just as we said and then look at what your product owner is doing is she actually doing what Q has been just talking about like really trying to make sure that those um those story points have a lot of impact a lot of um outcome behind them or is she just you know prioritizing some stuff for whatever reason and not having that that mindset of you know inflicting the most damage right because this is what you’re seeing right now the we want to have an impact we don’t do scrum to just you know trickle along like a little um like a little river and nothing is happening we want to get something done and one part of that is you as a scrum master and the team driving this stuff forward and getting stuff done and then the product owner making sure that you’re actually working on the most valuable stuff right and so I have an eye out if your product owner is actually doing that and actually it’s a great Point remember scrum master and product owner interlace they work together they should be in constant communication they shouldn’t understand what’s going on they should be constantly talking to each other right yeah because it’s a typical situation you can have a green Horner scrum master and a very experienced product owner you can have a very experienced scrum master and a green horn product owner you can have both cutting horns and both really experienced people so communication it’s key you learn from each other right if I scare a master is novice and benefits from having experienced product owner scrum Master is going to start realizing that the outcome is very important even though we are working on the output is what the output will bring us an outcome that’s very important if it’s the other way around right the product owner is not very experienced right it’s also starting to understand they the scrum Master is preoccupied with the process it’s preoccupying to get things out of quality and Etc perhaps I should pay more attention to that too you know and then they eventually start to see a because of the better quality before because of the better efficient I’m delivering value early to my customer and that is affecting my outcomes so there is a lot of benefits into you know working together and trying to understand each other uh we we always say we should break the silos right but I’ve seen a lot of situations or the scrimmers and product owner not necessarily because they wanted to but they created a silo of some sort right it’s like the when the scammars and say well I care about process process process the product owners say I don’t care about that stuff right but when we have good communication we we get perspectives from both sides of the house sort of speaking and we grow better as a team when we do that yeah absolutely and so just one thing came to my mind if you want to use like an Excel sheet but one that actually makes sense and that’s not going overboard there’s one somewhere on the scrumming side I don’t know if you have to be a registered scrum Master product owner to access it or if everyone can access it but if you if you feel the need to have something like that please use something that’s um that’s from an official source and please don’t build your own because that’s just waste and you’re probably gonna make a lot of mistakes in that yeah and uh again I go back to my pet peeve right do not overthink it right if your historical data says you can do 20 things a Sprint okay and when you are doing your planning you’re bringing stuff from the backlog in and Etc okay we got to 18. uh I’m not too sure we can do this other two things oh maybe we can split them Etc don’t be obsessed just pick up 18 and run with it right I mean I’d rather finish early it’s always can bring stuff in exactly right but do not get obsessive about trying to shoehorn exactly the same amount of things that you do every Sprint because hey stuff happens stuff happens all the time yeah right it doesn’t matter how good you refine some stuff there is always the stuff that you don’t know right and I think we should always consider another two things that’s very important one is no matter what you say there’s always shoulder taps and that can be an emergency can be a production issue can be somebody in the sea level suite and it’s something and you guys have to do it right now no matter what right we should always plan to have a buffer and a buffer to deal with interruptions and again that can be based on historical data can be something very simple way every time we have an interruption how much we lose from what we planned because of that interruption and if you take that that amount of interruptions into account you have a much more viable backlog that you can say okay we normally would do 20 things but when we get interrupted we usually do five less okay let’s plan to do about 15. it’s predictable for the product owner product owners like to have a certain level of predictability but we also deal with stuff that may happen and if nothing happens grab stuff from the backlog and start doing a thread yeah and actually now that you’re saying it I think this is really important to also understand managers right so in my experience few managers few stakeholders care about this kind of stuff right they want to see the impact and if you if you plan for I don’t know let’s say 60 points and you only achieve 55 points but you have a good explanation you have already an idea of why this happened right right why you fell short and you’re just open it in the review nobody’s getting killed I mean I’ve had this many times and whenever we did it even in front of very tough managers everybody was like okay cool it happens they have a plan right at least they have a plan to figure out a plan and in general they’re delivering stuff and so no big deal right and on the other hand if you are a manager and if you find yourself like being very strict with your teams and always laying like oh why didn’t you hit the 200 points or the the 60 points or whatever please please stop that because you’re doing a lot of damage that you might not be aware of because then they’re going to start manipulating those numbers then they’re going to be put on a lot of stress and you’re not really helping you you might be thinking that you’re helping but you’re actually causing a lot of damage you know look at what they have accomplished they have probably done a lot of good stuff and a couple points here and there don’t really matter it’s it’s not that big of a deal the important thing is to move forward to get stuff done to improve over time and that’s it you don’t need to be very picky about you know how you only achieve 97 and that means you’re failing yeah and that’s a great point you know and uh we always fail there is always this stuff that we don’t anticipate there’s a stuff beyond our control right I mean you can have a power failure because uh you know the weather or something like that we just had bad weather yeah at the end of the year right and uh that means nothing it means hey it’s a lesson that we learned oh by the way perhaps we should plan for power failures you know perhaps we should have a generator on Becca I don’t know right exactly but every time every time we quote unquote fail we learn something yeah right so as long as we didn’t do something very dumb or unprofessional or I mean that’s even dumb stuff happens right yeah even though stuff happens right but as long as we don’t plan to do something really dumb right uh we should always think about this is an opportunity that we learn something if nothing else you learn a we need a contingency from when this thing happens again or something similar happens right so we are not as impacted we can absorb the impact in a reasonable way which goes without saying right that we should never ever ever because you had your posted in there forget to have a Kaizen in the Sprint yeah it doesn’t need to be anything huge remember Kaizen is a small things that pile walked after a while and they have a big impact right but it’s important to have a Kaizen so a you know what guys we normally do daily scrum at 9 30 in the morning you know and by that time we’re already here for two hours why don’t we do it early let’s experiment with that that’s a simple question it doesn’t need to be anything elaborate can be tiny little things that help us get better at what we do and that should be something we always include in a Sprint and I know product owners oh man it’s I want a new features new stuff new stuff but if you don’t get your processes and practices better it’s going to impact your delivery of new features or you’re never gonna be as efficient as you can be absolutely all right man any other crazy crazy stories about capacity planning oh I have a bunch but honestly let’s leave it awesome I don’t I I don’t want to trust transform this into a horror movie you know even though I may get some cat soup and spraying here so it looks like a horror movie but honestly I don’t know how to go there I think I think we covered a lot of ground I I think that’s information that a lot of people should in consideration uh we don’t own the true we don’t know more than everybody else we just been around for a while and we got beaten by multiple things right so guys I think that’s it for today from Dallas I am q and the last word is always from Tyrion from Germany signing off keep it simple don’t create any waste in Your Capacity planning and then you’re gonna be good see you next time bye