welcome to the scrum sessions podcast from Amsterdam the first time since we start the podcast we are actually in the same room together welcome Gereon that’s true welcome to you too and welcome to you guys uh as Q said we’re here at scrum Gathering Amsterdam and have been uh taking part in the sessions and are here to give you our next installment of the podcast yes and today I chose a controversial team surprise surprise my friend so let’s talk about whether story points are really necessary okay so my take on that they’re not and here’s why because it’s one of those things that probably started as a very good idea and then it got distorted so things I see wrong with story points leadership starts to ask well girion how come your team has 15 story points and q’s teams at 25 or you know what we have to increase the accuracy of our estimation instead of HE we need to deliver value faster figure out what we need to deliver and then deliver really quick no let’s make estimates more accurate so that’s why I don’t like story points I actually see your point there should be a first should see should be a first time as well so I do see your point because there are some problems that are associated with it um but on the other hand I also see that there are some real benefits that you can have from having St story points and the first thing that comes to mind is release planning right you you can have like a good overview of how much there’s still left to do in the backlog provided you can actually estimate which I think is a big hurdle right people are always talking about story points but the real issue behind is often that teams don’t know how to estimate properly but once you have that down and you can establish some kind of velocity you can do quite precise release planning that is super helpful especially if you know leadership comes to you and says hey mm when is it going to be ready and you actually have to give an answer and can’t use that agile hippie cop out of saying oh yeah it’ll be ready when it’ll be ready no we have to give a date and so this can be helpful yeah but you see I I don’t disagree with that we have to provide relatively good estimation right and again let’s keep an emphas in the word estimation it’s not a guarantee right but when I first got into teaching it’s been over a decade now I always had this Pro story points not particularly me but you know in the team’s heads it’s like okay a one is half a day a three is a day and a half a five is a week an eight is two week or whatever whatever translation formula people come and that misses the no pun intended again the point no pun intended at all yeah nothing intend at all the point of story points right so this is the approach that I took and uh you guys probably are familiar with the with the podcast I’m a very big fan of backlog refinement I think the more you invest in backlog refinement it pays off handsomely right because things get simple you you you you spent time concentrating and understanding what the intent of the product owner was and how you can transform that intent into reality so in doing a lot of backlog refinement and teaching a lot of people who do backlog refinement and coaching people we found out this right I’m a le guy I’m an engineer by trade hey you know small items flow through the system faster everybody knows it nobody argues that because it’s very true so we spent a lot of time splitting stories and making those stories not only stories backlog items should be more appropriate right and we notice that we get them about the same size maybe a bit smaller maybe a bit larger but they’re about the same size and then it da us why don’t we just count them and what we notice is it became a much more tangible thing hey for instance gon team does 10 things in Sprint K that’s eight things spr we can still plan and I think we plan in a more tangible way because then leadership doesn’t start saying well how come here’s 15 and there’s 25 you understand that hey we can produce this many items over a time box over a period of time over a Sprint if you want to call it that way so I have had a very good uh experience with the past five years or so on just counting backlog items yeah and I will say that this is actually like how a lot of Canan practitioners do it as well right and there’s actually like a subgroup of Kon practitioners that’ll say estimation is waste right we’re always in the process of trying to eliminate waste and if we could eliminate estimation then we probably should right because it is something to learn to to do it takes time it takes cognitive uh effort um and I do like the approach that you’re using um and I’ll have to admit this so I want to have teams do the perfect scrum if they can right but in the in the sequence of a transformation they’re not going to get everything right at the beginning and truthfully estimation and story points is usually one of the last things that I’ll touch especially with a team that’s resistant and I often find that um for some reason software Engineers are often resistant to estimation and story points right and so if I have several battles I have to fight I’m going to choose them very carefully and it’s usually not story points that I’m going to fixate on first I’m you know I want to get everything set up and flowing and then this will come at a later point of time I do want to touch on it right but I can’t fight everyone at the same time right and so I’ll like as I sequence it out it’s usually in later stages and just because we don’t have the story points set in real nicely doesn’t mean that the team can’t start like delivering stuff and and go on this flow Journey right and so yeah I do see your point yeah and uh you see again I emphasize for me it’s not about story points or counting items or anything it’s about figuring out what has the most value in your backlog prioritizing the order of the things that you’re going to get out of the backlog in with the highest value first and getting the stuff out of the door producing stuff right whatever means you get to that I think is a bit irrelevant right if story points works for you it’s

fine if story points works for you it’s fine I personally refer that we take the approaches how can we deliver value faster refinement helps a lot on that most my teams they spend a lot of time in refinement when it comes to planning honestly 15 minutes is a slow day because we already discussed everything we just basically say he is there a holiday somebody going on vacation and off we go and it has been very accurate because we spent a lot of time understanding the intent and how we can deliver the intent so maybe it’s both maybe counting items if it works for you maybe story points if it works for you the point is how can we deliver the stuff yeah so I think we’re not in total disagreement here for once maybe because we’re in person I’m just afraid she’s going to beat me up but um so before people think we’re like totally against story points what are some of the advantages of actually using story points does anything come to mind for you well you can you can think of an abstraction of complexity and everything that’s involved and uh in a way that’s exponential right the the the whole idea is hey what’s the what’s the smallest thing we can do and we compare this the smallest thing we can do with what we have to do right now right by how many orders of magnitude we’re going to increase what is needed to deliver that so there is an abstraction to that right now the question too that as you point out earlier is do the people involved in trying to accomplish that that numbering that that estimation of some sort do they really grasp the concept on how to apply that measure that’s exponential right so that’s why I like the counting because counting is very tangible and it doesn’t detract from still understanding what’s involved in delivering the intent so one benefit I see of story points is that if I’m the product owner and I have to prioritize the backlog um maybe I have an idea of the value of that specific product backlog item but if I’m just taking like an average item and we just have one average can I actually prioritize the backlog because yeah I know might know the business value but if like they have the same same effort size I’m missing one of the pieces in of information so what do you do what do you do do you prefer to have like one average item or do you use like something like T-shirt size where you say we have an average smaller item an average medium item and an average larger item no what do we normally do is we actually can still prioritize by value regardless of items being uh equivalent in size right because we can use several techniques but I normally use a technique called Val valuation which I actually put the items in six buckets and without getting too much detail because that’s probably for another podcast I have things like what’s the commercial value of the item is this item something that’s going to increase acquisition and or and or retention is this item enable us to do something we couldn’t do before right so you can create several buckets and use those things to prioritize the backlog and you’re going to notice that some items Asha going to fit in multiple buckets that’s a hint that hey that’s that’s one we should do first right so I think regardless of points or or counting items you have to be very aware of the value that an item brings and I think the word value tends to be something like Pi in the sky but we have to bring it down to the point that says what are the benefits of actually working in this item first instead of this one here and that’s something that’s regardless of pointing or or counting or whatever and uh I think a lot of times product owners have a little bit of problem prioritizing things because a they tend to use a single technique to prioritize I prefer to use multiple ones uh I normally buckee things first and then I pick up things that are in multiple buckets well that’s higher priority right things are in single buckets okay so what’s what’s the bucket that matters them most for me or is the one of commercial value or is the one about enablement right and then I use different techniques to actually number 1 2 3 4 5 whatever inside each one of those buckets and I think we probably should do a podcast on prioritization next but I think that’s regardless of how you estimate or not you have to understand what should be delivered first and then by whatever technique you can plan in the order of the deliveries and how early how soon you’re going to have that to Market all right there have it guys Q’s been haunting me this whole conference because he was like so rail up about the about the story Point issue and so know we’ve had it and found out we don’t actually have that much disagreement on this one I still like them I I want to do them but I do see them um as one of the more difficult things U that are beneficial but yeah I totally get what he was saying and that works well yep guys thank you very much I hope you actually get to do podcast in person again very soon this was the first one is not going to be the last one again um like us on YouTube give us feedback ideas that topics you want to be covering and uh from Amsterdam I amq and he always has the last word I know everything has already been said so thanks guys and hope to see you soon bye-bye bye [Music] [Applause]