 This one was a impromptu session that was put in place because one of the speakers dropped off But I guarantee you it will be more exciting than the speaker that dropped off There are a bunch of topics we listed because that's something that we I've been hearing from a lot of people saying you know We need to talk about this. So I just listed no estimates no project. No backlog and this is some of the stuff that this been a lot of noise in In this community and outside the community around what's happening And what I want to do is over the next 45 minutes kind of spend maybe a good chunk of time first on the no estimates Movement that's happening. We spend enough time discussing that as a group and then we will move to other topics All right, this is not going to be a presentation Right. This is a fishbowl How many people have attended a fishbowl before a quick show of hand? All right, so the way a fishbowl works is basically we're going to create a circle over here and Around one of the table and then that would have let's say five chairs at any given point in time Four chairs can be occupied one chair is always empty if a new person from the audience wants to come and Present something add in a viewpoint. They take that chair one of the four people who were already sitting on the chair would leave and Keep that chair vacant for someone else to come in so this allows all of us to participate in a constructive manner Without it being very chaotic, right? And if that doesn't work really well, then I've got posted notes as a way of You know making that noise a little bit less and we will see how it goes right given we don't have too many people I think this format should be good enough for now How many people are familiar let's kind of dive into the topic right how many people here are familiar into the whole no estimate Movement. What does that mean? Two people three people show your hands. I know Okay Not many people Should I kind of take a stab at defining what the idea is? How many people believe estimates are absolutely necessary for running software projects? doing projects without this Estimates is such an integral part of software development How can you measure the velocity watch my video on agility? Velocity is killing agility defining what no estimate or the the idea behind the no estimate movement That's right, and I'll step a little bit back first even to explain Why we came up with relative story Relative sizing basically story points or other kinds of things, but where we came from let's take two minutes do a quick kind of Recap of how things have evolved Everyone's I'm sure familiar with effort estimation estimating projects estimating tasks in man ours Women ours whatever you prefer to call them right So back in the days we would say these are the list of things that needs to be done Each of these things are estimated in ours or days depending on some kind of an effort But that was referred to as effort estimation How long would it take for one person to finish this particular task or this particular feature? Whatever you're talking about, right? so let's say ours per person or Per week or whatever and what was the problem with this approach? Was there a problem with this approach effort estimation? What was the problem? So let's make sure we're all having one conversation So you're saying that when it was 50% done it really didn't mean it was actually 50% done I'm not sure if there was a problem especially with effort estimation, but we'll we'll take that point you had a point It is estimate right so One conversation or we'll switch to post-it notes So the estimate to what was the actual What we were finding on where what we were hoping is the gap between them would be Relatively less and bit more predictable because we are basing our plans on it, right? But if those numbers kind of are all over the place It was just getting more and more difficult to to use this as a measure Effort is not same as duration does that make sense? All right cool It changes based on the person skills. So this is very person dependent someone for someone This is a two-hour task for someone else. It could be an eight-hour task depending on their skill set So it's very person dependent, right? You had a point Same point. All right, awesome So so it expected more you need clarity to be able to be good at this, right? So these are few problems. We can spend the rest of the evening just talking about the problems, but that's not going to help us Right. So what did we do? How did we address this these problems? We try to address this problem by Buffering yes, there was one technique looking at historical data for top estimation trying to give different estimations and How did that work? equally bad Right, then someone came up with a very smart idea called story points Right Anyone knows who came up with the idea of story points? My corn he gets way too much more credit than he deserves That's recorded on the video. This was back in the extreme programming days This is where story points come from And the idea was as simple as this which of these two as longest longer The bottle everyone agrees any doubts in your mind? You're hundred percent sure By how many centimeters? Now I'm forcing you to estimate or guess But the first question You were not guessing you were pretty sure, right? So this was a basic premise of story points and the idea was that human brains the way that we have evolved We are very good at relative sizing, but we're very bad at absolute measures So this was an absolute measure, right? You're saying two hours four hours ten days twenty days, right? This is this is something we humans are not capable yet and Probably the next 25 years. I don't see us getting better at this So the idea was to move away from this and move to this notion of relative sizing This is relative sizing But how does this help us? I'm kind of taking all the way going back talking about why this was bad Why story points was a good idea then I'm gonna talk about why story points is a horrible idea Then we're gonna talk about, you know, where do we move and then we'll open up the fishbowl once we've laid the foundation Right, so How do we use story points? So we basically relative sizing, right? So we've got relative sizing we look at two stories two tasks and we can say one is more complex more Volatile more ambiguous than the other one Right, but we still don't know how long it's gonna take to do this because that's very dependent on the who the person's gonna work on You know, what's their prior knowledge skill levels and also, you know the context of what you're trying to do So we came up with this idea of from effort estimation. We moved to relative Size estimates and a lot of people say, you know, you can take the relative size estimates Basically what we did actually let me kind of recap, right? So we did relative sizing we took bunch of things put them in different buckets and we said this is one point This is two points. This is five points or three points five points eight points. We used a non-linear scale Right. We use Fibonacci series or something else, which is a non-linear scale To to put these story points Everyone's with me so far and what was the rationale behind that the uncertainty, right? That's too complicated. Even you don't remember what it is. So let's simplify it, right? To do to do it to D link It's so hard. I can't even say to D link The mapping the direct mapping between effort and the actual points, right? so when when someone says something is one story point and Something else is two story point. It does not mean that this is going to take two x the time to do this everyone's on agreement with that and Then how do we calculate velocity? We just said we are going to do this so that you can't apply arithmetic on it And then we turned around and we said you add all the story points and that gives you the velocity So my velocity this time is 15 Next time I'm going to pick up 15 one-point histories and Guess what it's going to be a disaster So people were running into all kinds of challenges, right? One challenge was Even though we talk about relative sizing in the head Developers testers still keep thinking about effort. It's very hard to get out of that because for years You've been slapped on your knuckles and now when you say hey, give me a relative size You're like how many hours in my head? Oh five hours. So two story points and That was one of the big problems The what was the other problem with this problems with story points guys? But the whole point was not to arrive at numbers Right and so your point is the management still wants a time-based cadule and So inevitably we were forced to take these converted back to ours our days and show a dot on a timeline saying when this is going to hit that dot and That was a problem Not necessarily in my opinion with story points itself, but with the expectation of What you're going to derive out of this But that's what you would account into the complexity, right? It's it's it's complexity is simple But the number of times you need to do this a number of places you need to do this This is bigger than this other thing And we could do that. I think that there it has an advantage over effort estimation in my opinion, right? So it's not necessarily a problem. We want the graph to go up up up up sales go up revenues go up velocity go up Employee satisfaction go down. So just to summarize this point quickly is a Story points itself is okay But story points with velocity led to this whole idea of it should keep increasing every sprint You need to keep getting better every sprint and when we started doing that It was very easy for smart programmers to game this Management wanted this to go up. I think that's the point you were trying to make Yes, we all agree that it is it's a tool for us to get better predictability But it ended up being a tool that I've been in companies where I've been asked why is the velocity not going up Was there ever an expectation of velocity going up? But you're doing things and you should get better at this, right? So shouldn't the velocity go up? comparing teams two teams velocity because one team is measuring in cookie points another team is measuring in beer bottles and people started comparing How many cookie points versus how many beer bottles and didn't really make much sense Right, so that was another problem. That's the second problem comparing teams But that was a hard problem because if I put myself into the the executive shoes, right? I want to know which of my teams need help Not that I want to monitor them But I need to know which of my teams need help and what tools does agile give me now to do that and Often the answer the naive answer was let's look at the velocity if these teams velocity is not good If this team's velocity is not going up, then these guys are bad. They need help But that created another train wreck, so we'll not go there, but that's another problem Shall we kind of summarize quickly because I think we all know 20 other problems that were there But one problem no one's spoken so far and I want to bring that because to me That's the most important point is story points in velocity focused way too much on output and Then focus on outcome. Does that make sense? I'll repeat myself Story points velocity and other kinds of things focused way too much on output Not on outcome What's the difference between output and outcome? Output is the number the number of lines of code you wrote the number of features you build the number of Tasks you completed yada yada yada outcome is Why were we doing this in the first place and if we did this did we actually achieve what we were trying to do our? Hypothesis was for example If we reduce the number of steps that it takes for someone to do a task Then the number of people doing the task more frequently will go up That's the outcome that we want But we got so caught up in measuring these and be so happy that we are achieving our velocity sprint on sprint that we forgot Even to measure the outcomes Yes That's all in theory honestly In fact in fact if you see someone's velocity pretty static, you know, they're gaming the system That's the first indication someone should look for if your velocity is pretty Constant it's being heavily gained Because velocity being constant is just in theory in practice. I have not seen this in the last 12 years That's what traditions do right you tell me what data you like to see and how you like to see it I'll show you that data Yeah, you're right, but I would strongly disagree with the second point that measuring value is very hard I I don't think measuring value is really hard because if you can't measure value Then you might well, let's shut your shop down and go because How do you know what you're doing is actually making any difference? Whatever you're doing it for but it takes a lot of time to do it so people like Will take that calculus into their head and say, oh, this is what I'm gonna get if I do it Okay, but you can't see that I mean I will make an extreme statement I Think you're right for some companies. It's it's hard. It takes while But I don't think for all companies. It's the case Right there are there are enough companies where they can find ways of measuring value in a much earlier way Maybe not 100% but some point of it because you need to validate whether you want to invest more on this or this is good enough Or you should pull the plug Right. I mean to me. That's that's an important point So these were all kind of the challenges that were occurring and what was the solution to this or what was the kind of new Idea around this is how do we tackle this? Has anyone seen this Jeff patterns? presentation on Flipping the iron triangle. Yes. No Let me erase this off the board No, this does not help. Thank you. All right, awesome Everyone's familiar with the iron triangle scope Costs time So I think traditionally with the first model that we defined what we were trying to do is we were trying to fix the scope and estimate The time and the cost They are a factor which builds on each other But we will try to estimate time so we can estimate the cost and we would determine whether how to balance this Triangle right and it turned out for all the reason we stated in the past that this was a terrible idea and then a Bunch of people said what happens if you invert this That's a interesting idea Time and cost is fixed What does that mean? you have You have a fixed set of people you have fixed cost of running your business etc etc so Kind of your cost is fixed in some sense You know you fix a time box Which is two weeks three weeks five weeks one week whatever works for you and you fix the time Then you estimate what scope fits into that time box This is where story points and other kinds of techniques kind of came in where you would go with the gut feeling the first time You would look at how many story points you completed next time You would do a projection based on that and then you would say okay Maybe we can take on so much so you're estimating what scope you can achieve in a fixed time Right, and then people said while this was a good improvement from here to here. We still have Not really solved the problem for all the reasons we were stating and then what's the no estimate movement now coming to the actual point Right, so I'll pause here What I want to do is maybe Get people to work in the groups a little bit so that everyone's voice can be heard and you can Think about what the no estimate was trying to do Yes, no, no, so this is no estimation is not yet here. This is basically the story point approach This was the effort estimation approach This is the story point approach or relative sizing approach the no estimate approach is a different approach Sure, so this is one way of doing the no estimate approach Okay, this is one way of doing what I was trying to say is maybe we now I've bored you guys enough Maybe we do a smaller group kind of a discussion saying what a no estimate would be right? We've seen that we've seen the problems and what should be the next evolution So I was kind of hoping you suggested one way of doing this. There are many ways of doing this Right, so can we do quick group discussions at tables? Yes, let's time box this for 10 minutes. I'm fixing the time box Discuss in your group. What all livers do you have? We talked about these livers here. Are there more livers you can play around with? Right, that will actually help expand the context Two minutes so kind of trying wrap up your discussion and come up with a conclusion people have woken up Does any group have I as I was walking around I saw still a lot of people defending why they need estimates And that's brilliant But it's not gonna help you as Einstein said doing the same thing over and over again faster is Height of stupidity you need to look at There are certain problems. Is there a different way whether you do it or not is a different question But here we are trying to explore is there an alternative, right? So if you're just defending why you need estimate, you'll never probably figure out Hey, there might be a better way to do this and guess what there are bunch of companies out there doing it So there's something to it, right a Bunch of companies a hundreds of companies. I don't know lots of companies Doing stuff out there without estimates Sorry, no, he's asking me to give data on how many companies are doing this and there's no way to know that data Unless someone goes and does a PhD research on this which will be published five years later by that time No estimate would be irrelevant Which table has actually a solution of a no estimate approach Potential solution I like that go for it You need to be crisp one minute done Awesome, how do you know that working in scrum highly motivated highly self-organized teams working in scrum seems oxymoron to me Never seen it. Sorry a seeding approach. What does that mean? I Don't So This is I So let's pause on that because I I'm not I'm I don't think we're gonna be very constructive going into that debate I'm saying let's look at is there an alternative way and then maybe you can decide, you know, what? This seems insane. These guys are stupid. I'm not going there or you can say, you know what this kind of makes sense Let me try it out on the next project, right? And we will see so what I'm looking for is ideas from tables where they have come up with a solution Or maybe someone's actually experience doing something of a complete no estimate approach, right? I know you've you've been raising your hands for a while. So we'll go there We thought about The future How sophisticated you can make the feature So what we thought this Is You're saying if we added another liver over here, which is basically you took the scope and can we slice the scope into grades Right into grades or into levels of sophistication or whatever terminology you want to use and maybe This is the bare necessity bare minimum bare minimum marketable feature and That minimal marketer feature you put out there and then you might decide you want to do more Scrap it. What do you want to do? So you're adding another liver, right? But Go on like what's the solution? This is good. But what what else? But you still need some estimate yet And you know that okay, you've got 10 features So if you want to take pictures to be done, so you want to be a Cheshire for improvement, right with the minimum, whatever the grade that you want, right? So Once you have done that, right, you continue to sort of add This is okay, let's let's talk about this solution It works when I've already got the project when I already am executing the project and I want to incrementally Deliver stuff, but when I even need to get the project right at the beginning, right? And you want to see the feasibility when I want to get the funds allocated either externally or internally I need to have some projection of the effort It's going to take and the company might decide you know what this is not worth Getting into at this point because it's going to take us two years to do it and it's going to cost us so much money Right, how do you tackle that question? What you're talking about is great it at the execution level You can start slicing and you can start doing things, but a lot of people get stuck even in the first point, right? So I guess it's good to split them into two parts and tackle them separately So that's where the title was no projects as well We are running out of time we have zero seconds left You can give us the answer Oh there is no such thing, but I have enough experience not having estimated for the last eight years and having Delivered successful products in businesses and I can quickly talk about some of the techniques we have used These are not silver bullets. These are not going to work in every context But I can quickly jump through and summarize what we have tried to do Right now I'm doing this at hike messenger It's a it's a hundred million user company And it's a it's a it's a pretty sizable. We have something what we call as an opportunity log These are all the kinds of things that the company could be building today to make millions of dollars or to make millions of people impact on millions of people We take three things Which we think are the most viable ones and we run through a one week Discovery on each of them during this one week of discovery, which is a fixed cycle We are figuring out what is the core hypothesis of this idea And how do we validate the core hypothesis of this idea? So all you get is one week you don't get more than it's a fixed time box You basically run in one week and you either have to come back with solid data That proves that this is something that the company should invest on right if you can't come back in a week This goes back into the backlog. We might revisit it at some point. You pick the next most promising idea from here Let's say you take this you go through one week of discovery There are a list of your riskiest assumptions riskiest hypothesis you run some experiments you validate that and you've got some data to You know sometimes it takes Sometimes in a week. It's hard to get all of these data, but that's where a lot of hacking Skills come in right what we do and what how we collect data now Let's assume some of this proves that this is actually going to increase our retention This is going to increase bring new user base other kinds of things. So we have some high-level Company-wide okay ours or metrics that we look at which which impacts the company could be things like retention of users could be Things like onboarding new users could be increasing sentiment analysis of the use sentiment score of the users, etc And what we do from there is basically if one of the projects satisfy one of the idea satisfy The need we will take that and that would go into what we call as a dual track Development cycle where on one track. We are constantly doing discovery of What is the next most important thing that would add value? Let me just complete because we don't have time hang on Let me just finish please We've taken bunch of hypothesis. We validated hypothesis. We believe that this is a thumbs up We need to go with this. We run this through a discovery track. This is an ongoing track. No time box So one other liver that we talked about is the time box we remove the time box liver and basically we run discovery in parallel we run delivery at every Discovery we produce some kind of a validated result that goes into a delivery track Which constantly keep adding stuff pushing stuff out into production, right? And at any point in time you can chop this off saying this is not making sense or pull this off So there is this notion of moving from Output based measurement to flow based measurement where we are looking at how much value are we adding by constantly looking at flow And splitting this into a discovery track and a delivery track helps us validate something before we start building it Validating the value before we start building it This is not going to do justice to the topic, but I know you had a question and then we'll come over there Hang on The company only has one week. We don't know We don't know we have no idea. We are saying one week is all we can afford It's a it's what money can the company invest on an experiment Choosing which work you will do based on the value it will provide Instead of choosing which work you will do based on the estimate of how long it will take That correct. That's correct. That's that's one essence of it but the other important thing is You have to have actually validated that it will add value before you start building it And then it doesn't matter if it's going to take one week two weeks three weeks But the other part to it is that I don't want to invest three weeks, but that's too long For something to backfire. So we will try and slice it down sophistication livers with one idea Right, we want to slice it down to the least sophisticated thing that will actually help us validate that what was the hypothesis Validated over here is actually coming back as real data Right. So instead of focusing on the time We are really focusing on validated value being added and both of them happening in parallel So you're prioritizing based on what your ROI is going to be essentially right based on what you validated And so then so I'm trying to think about in a larger company How you apply this right where you help leaders move away from feeling if you need to understand the investments going to take up front instead being able to communicate validated Hypothesized ROI and say this is our biggest ROI at this point So this is what our teams are going to chase after that at any point after you've applied those sophistication Lovers if it feels like this isn't what we wanted to be you just end it and pick up the next thing. Yeah, it's Right now at this company. We have 12 teams parallely doing this And this is basically happening in parallel at 12 teams level So it's not just one project there are multiple, you know teams working on this Hypothesis by hypothesis One hypothesis at a level a Hypothesis can cut across 20 features a hypothesis can be a dot on the screen Release is happening every single day Not to 100 million users but to 100 users point 5% of the users 1% of the users 5% of the users 20% of the users 100% of the user When the value is actually validated in the market, so you had a hypothesis you ran a bunch of experiments You said yes, this makes sense from the small database from the small hypothesis that you ran You feel this makes sense then you're going to invest a small amount of time to quickly get that out to 100 users 2,000 users to whatever statistically significant number of users and then you would decide whether you want to roll it to the Next set of users or you want to pull it back? Why should I care if it's waterfall or not it works for us It's actually really helping us. It's saving us millions of dollars of wasted Effort building stuff that no one wants Yep, I'm out. I'm out. I'll be here. I will be happy