Creating efficient, accurate, software estimations | Panel discussion | #LeadDevLive
Hello everyone and thanks for, the introduction, mary. So our panel is about estimations. Uh do you have a delayed, project at hand, uh don't worry you're not alone here. Estimations. Are difficult to get right, and could we really, get this right reliably. And, or do we even need them in a team or in the company. Today we'll have dianey, dominica, and amir, on how to solve the problem of estimations. If. Hi. And before we get started, let me introduce, our panelists. Dianey, is a devops, analyst, and engineer, for kunan and nagal's, online solutions, department. She joined the company, in 2011. And she's had different roles, from being a developer. Analyst, to being an engineer, on the info team. Domenica, is a software, engineering, manager, in factor technologies. Leading teams with empathy, and managing, projects, with radical honesty. She's passionate, about agile. Hard workman. Amir, is a software engineer, and a tech lead at google. He leads a team focused, on developing, products to help small business owners build their online presence, and connect with, customers. Without further, ado let's get started. Uh first question, a warm-up question from a panelist. Give us an example, of how you've gotten estimations. Wrong and what are the dire consequences. That, you have to handle afterwards. Amir maybe you can get us started. Wow, uh. Tough warm-up. Um. Okay yeah, this is a story, uh, of, very early in my career. Um. When i gave an estimate. And we had a user. That was shouting, and screaming about a feature that was, was missing, in a new system we built. And i was young, keen. Ambitious. A junior developer at the time so i jumped up and i said, hey look i've got an idea for how to solve this and i can get it done in two days. No one had even asked for an estimate i was just so keen i had to provide it. Um. So i got to work right away, and i ended up working on it um. All week. Uh all of that weekend. And actually all of the following week.
And Most of the week after that so um. It actually took me 14, days, in the end. But you know in that time i'd been working flat out. I'd solved, some really hard problems. Most of which i hadn't envisaged, at the start. Um, and i was actually really excited, i'd. Worked really really hard to get something ready. And i knew that i'd done a really good job, um. And i kind of assumed that everyone else would feel the same way, where once i, once i delivered this and, now that it was done and that feature was there. Um. But i was wrong, i was very wrong. Everyone was very unhappy, my manager was unhappy. Um, and the user wasn't happy as well. And, the reason for that was. I had said it was going to take. Two days, it took 14 days. Um. There were a lot of things that might have been done differently, if if uh. If, i'd given a better estimate at the start if i if i said at the start it's going to take two weeks. Um. And this is the point. Where i really realized, how important estimating, is in software engineering. You really need a good estimate to set the right expectations. And. Like a longer but. Um. A. Longer but more correct, estimate, is a lot more useful than a shorter, but inaccurate. Definitely a good takeaway, so medical i see you're you're, pretty happy to hear that anything to add here. Yeah actually. It's not exactly about, estimation. About why you need some buffers, because even if, everything, is okay. Everything can get ruined. So i have a story, when we were working with my team of software, and hardware, engineers, on an uh, medical. Electronic, device. And, everything, seems. Seemed very, okay we were ahead of time. And one day late february. I call my local, prototypes, manufacturer. And i say hey, i need 20 prototypes. In two weeks. Like usual. And he says no way. It's new year in china. And chinese. New year means two weeks vacation. All manufacturing. Stops. People go home. So. You can't order from there in this time mostly. Turns out all people, from poland. Who didn't know that, turned to my local manufacturer. For rescue. So even though we weren't ordering from china. We got delayed, and missed an important, milestone. With clients. So really. Estimating. Is super important, but also adding some buffers, for, for your estimations. Makes everything safer. Cool. Um it seems like getting estimate. Right is definitely a challenge. Uh but do you think it's still worth it to go through that process, danny what do you think. Well. It is worth it because, it allows, us to. At least. Have this common conversation. On. What do we really understand, and what's the the path to be done. And. Of course sometimes. When, if the process, becomes too long, and too. Stressful. Let's say it takes. It's it's tiring. You might, feel like, oh not again i have to estimate. What this what's this for. But. That, always. It would always be necessary. To answer, the question, when something is going to be done, so there's no way that. Any, stakeholder. Involved, will be. Happy, without, having, at least a slight, idea. So of course. It can be. Very tiring and boring at times but at least, the fact that it allows us to sit together, as a team, and you know talk and try to get deeper understanding. Of what's the task to do i think only that already. Makes it worth it no matter how tiring, everything around can be. That's my opinion. Yeah that's a that's like a point, uh in my experience, uh as you mentioned we're working with other stakeholders. Whenever we mention estimates, then, it gets confused, with the concept, of deadline. So, um, dominica, what is your thought on that. Yeah that's the exact. Problem. We all need to solve. So make it clear. If we are talking. Estimates. And just. A bit guessing, and basing on our, experience. And when we are talking, about, binding, deadlines. I said the. Rule, that i, shout, at, anyone. At my company. I say, estimations. Is not, declarations. And as long as, we all don't understand, that, this. The conversation. Is just not going to work because. If, you meet somebody. At a coffee machine as just ask them, hey, this. Little, feature, is it difficult, and you're. Friend, developer, says no it's okay. Uh i think. It's easy we'll do it in like two weeks. And you add that to your timeline, as a manager. It like makes no sense. But, if we don't make it clear for everyone that okay now we need to talk deadlines. And now we just estimate. We won't go anywhere. So this is. Crucial. Anything to add i mean. Yeah i i'd, i'd agree with that, it's very important, uh to echo that message that estimates, are not, the same thing as deadlines.
Just You know. Maybe, point someone to the dictionary and look up the definitions, of the two they're very different. Um. But, you know it's also important because. Uh you know if we treat them that way, um. We can, we can sometimes. Uh end up uh providing an estimate that matches. You know that the deadline or the desired, date, um. And then sort of working backwards, from there which is which is not the ideal state. At this point i would like to uh, uh. Point from my experience. And. Of course, as you said amir. It's very important to know, to. To to have in mind the difference between a deadline, and an estimate, but. What if. Your whole surroundings. Are driven by deadlines. What if some people, first decide. Okay. Until. I don't know end of this year. Uh this must be ready, so what happens then. So i can tell you for example in my experience. In. The company where i work, it's. Not unusual. That we are, kind of, deadline, driven, at times. So sometimes. I mean it's not uncommon, in the past, we have caught a deadline. From top management, saying okay until, this has until, but you know that the funny thing is that they don't say the whole package, has to be ready until that, date. But they say okay we have this deadline. So tell us what can we have until that date. So. It kind of, makes the whole uh discussion, a little bit uh from the other perspective. Because, once you have that deadline. And then the, what we have had to do is to okay keep informing, okay, until that day we can have this and this very so it's the whole, negotiation. Between the project managers, and the product owners, on, what is a minimum, viable, product, what is it that they can have until that date so, it's a funny approach, i'm not saying that it's the, right one that is the best one but it's also, something from my experience, that sometimes. It's inevitable. That to have a deadline. Fixed, and then you gotta, somehow, find a way to to. You know, cope with it deal with it so. That's what i want to do yeah i can definitely, wrestle. With that. Go ahead. Yeah. That's that's a really interesting you know decision, makers. As you talk about that and actually, decision makers could be. All of you watching on the call as lead devs, um. You need some idea of how long different parts of a project are going to take to make that. Sort of opportunity, cost decision, of do we do this or this. In order to meet this deadline. Um. And going back to. You know to the question, why do we need estimates that's uh. That you know that's one of the reasons i'd give um. Because it's, a question that's often asked like you know estimates are always wrong so why do we bother with them. Um, but that uh. That example from diony i think um, illustrates, just, you know uh just exactly why they're useful. Yeah, and sounds like it's not only just estimating, the task that is important right, there is also like the scope. Also, um. Thinking about the actual time that we have it seems like that is also. It could be challenging, to estimate that right what do you think dominica. Uh, yeah. If you. Have to like. Say, how long this big big project. Will take it's really difficult, and. Every level of estimations, is a bit different. But you, you need to to make sure, that, uh. Not, only you talk about time but also about priorities.
So If you're. Talking about a big project, just make sure you know what the must have without. Which, finishing, this makes no sense. And and go with that also. If you have uh. Like deadline, driven. Management. Let's say or. Or, you're really delayed on your project and what's now we need to release, on this and this date and what happens, now. Is to really talk about priorities. And. Look through. What we can cut out. Uh. From the scope, to. Achieve, what's. Uh, what is a success, for everyone not only the team but also. The product. Uh. Owner, or our clients. So priorities. Together, with time is as a good, start, for discussion. Great so it seems like we covered, a bit on like what happens with fixed deadlines, the difference between deadline and estimate, how about we just. Switch gears a bit and we move on to, giving, our audience some tips. Can we get estimates, right can we do that well. Reliably. Maybe i'll start because. Okay. I'll start with, like, continuing. What i what i just said so. So it's a, combining. Time and priorities. And generally. I, found, talking, to people, about, time. Very useful. It's maybe not revolutionary. But. We often, don't talk about time so if you say something will take a week or a month. Add why you think this way if someone else says it will take a week, or a month ask them okay but why do you think this way what you counted. In this estimation. And what's not included. Because talking about time, with our teams or stakeholders. Uh creates, common, understanding. Of time, so everyone. Is involved. And, thus we constantly, improve. Uh our team's estimation. Abilities. Uh. So diyani, you probably want to add something now, i finished. Yeah sorry and i just. Said. I said, technique, can't give reliable, estimates, because. There's this, i don't know if you've heard of it but there's this planning, fallacy. Which says that we all humans have this tendency, of. Underestimating. How long it will take to, finish a task. So it's kind of a bias, and optimism. Optimism. Bias, that we have. We have this tendency. So. The fact that we assume. That, it's, just an estimate, just as emir, said it's an estimate, it's by default something that can or cannot, be true. It's already helpful. But. What about, uh. Acknowledging. That. The fact that it might be. That. There may be more than one result. On. More than one. Result, of this, act. As itself, of estimating. So for example, we say um. Okay, we, believe it's going to be ready, uh. Until. Uh. End of the year, but end of the year. Is. It's a it's a it's a value, it's a it's a it's a single, body, it's a it's a one single event what if we give a range, instead, what if. It's gonna be, ready. Uh. With, a. Certain, probability. Uh. Till the end of the year or earlier, than that. So what i'm, trying to get into, is, what if we use a probabilistic. Thinking, for giving. Estimates. So this is what i can give you my own experience. We've been using. Method, called the monte carlo, simulation. Which takes the historical, data of the team, and uses, it to create a probabilistic. Forecast. On how. Long it's going to take until you're ready with some, certain amount of tasks, so. You will communicate. Something, like. Uh, with. 80, percent, of probability. It's gonna be ready. Uh. The, end of march or earlier than that, or if you want to be, more, this probability. Will give you, the level of confidence. On the, on the. Um. Work that you're saying. So if you want to give more confidence, then you talk about some 90. Probability, or something like that, so this is an approach that we have been using in our team. Uh. Or in our department, for the past years. In order to cope with this deadline, driven. Development, that i told at the beginning. So since that is negotiations. Going on with this, minimal viable product so we also. Do a forecasting. A forecast, continuously. Means we give a further. Estimation. And then we refine, it, as we know more, because at the beginning obviously there are so many unknowns. And variables, that we don't know so we refine it more and more and more. And this is an approach that has worked for. Do you take into account the complexity. Or who is going to do the project. Well uh, of course. This. Works, also, for teams. Who have not worked together, before but you need to have. Some, some, uh, amount of history, so some amount of. Uh. Resolved. Issues together, so that it can be used as a source, for that, monte carlo simulation, so, yeah. And as i said it's a probabilistic. Way of thinking, so. You wouldn't, it would take, take into consideration. All those variations. Like, the team fluctuation. Or. The size, of the items, some someone's. Some items are going to be bigger. Than others and so on so it all flows, in, because at the end as i said it's a simulation, so it's a probabilistic. Way of thinking. I see, amir what's your, take on. That. So. My my number, one tip is um, don't, be afraid.
Of Getting it wrong. Um. Uh, estimates, are never gonna be perfect, and you know if you're using your best judgment. Uh collaborating. Well with the team. And you know your product owners, ux, everything else. Um, and sort of being. Aware of some of the blind spots you might have. That's that's really the best you can do. And, you're not always going to get it right um. So don't beat yourself up uh, for, getting it wrong. Um but also you know, don't be afraid to sketch out, estimates, when you know your estimate is going to be wrong if that makes sense. Um. Like that sketching out process in itself can be, can be really useful. So in this case uh it seems like there are quite a lot of unknowns that we need to deal with in estimation. So how do you allocate, buffer for that. What is your strategy. Maybe domain. I ever wanted to say something so start and i'll add. Later. I i was just going to say um. Yeah, that there are going to be unknowns, um that's the nature of what we do as software engineers. Um. We are. Exploring, uncharted, territory we're building new things. That have never. Existed before, um you know if it already exists, then why aren't you using. The, thing that someone already built, and provided, a, solution for right, um. So, you know it's not repeatable. It's not like, um. Uh you know. Running a marathon, you can you could do that same distance, a number of times and understand, what what what your time is. You know or various other things that that are easier to estimate. Um. But what you can do is you know break. Tasks down into smaller chunks, um to get feedback, on what you're doing early. And um. And draw a little bit on, uh. The experience of other people that have done something similar as well. Sorry dominica, back to you. Yeah i, believe, ianni, also wanted to, to. Hear something about buffers, and and that's something i. Think is really. Uh. Useful, because, there are things that are maybe unknown. That happen. Regularly. Like. I know maternity. Leave or paternity, leaves or holidays. So there are a lot of calendar, things you can add to your project timeline when you're estimating. This, bigger. Picture. Also, sometimes. If you work in defined. Time boxes, like i don't know sprint, and scrum or whatever. And you plan, for next one, it's, useful, to take a look at the calendar because if half of the team is leaving for holidays, and. Then. There is a, company, party, in next week then probably you won't be. Able to do much, in this, spread let's say. But. Like some funny buffers, i sometimes, added in my projects, was, a. Skiing. Season. Buffer, because, i had a lot of skiers, in my team so i knew that, summer, in, winter, people will take a week or two off to go skiing. Uh, also. Yeah i already, mentioned paternity, leaves but also. Um. Buffers, for sick leaves when you leave in in the place where, weather, is, ruining, health of everyone. In autumn or winter which is what happens in poland. Very often. From from other things. If you have for example to work with some other, people in company. And you know. Then. That you need. Time to coordinate. Ad buffers for that i once worked work on a project with a team from different company. And they really, pushed, for, the. Very very detailed. Timeline, but they also wanted to be. It to be hard as possible, so i was like okay. I work with radical, honesty, so i like, show them okay this is our. Really really, tight, uh. Timeline, i added this buffer here this buffer here this buffer here this buffer here. And they were asking, for two things one okay but this buffer, they they are not really, useful, can we remove them. And, second, what i know that they talk to, a major, stakeholder. Okay. They. Will do it faster, but they will just never admit, that.
How Do you handle this situation. Why are stakeholders, push back on the buffers that we add. I always say. If you want, to hear the truth. That's the truth. And if you want to hear it will be faster, i can, tell you that but this will not be true. So if you want something faster, we need to cut out. I think. I just something, quickly that came to my mind is that, uh, you, you were saying that communication. Is very important, you know to keep the expectations. You know, right. So, what if every time, like you say if the stakeholders. Want to take away all those buffers, but if every time then you just, go with them through the scenario, what happens, if it we don't uh. Deliver. So what are the consequences, what do we do so, you know to have like a kind of emergency. Plan. And and practice, it every time so. Doing that regularly. Uh, might help also to build more confidence. On. And also to relieve a little bit of the pressure, of the team. Well i think. So it seems like from my experience, asking. Developers, to give estimate, it's more difficult than asking them to do the actual test do you have similar experience and how do you motivate, your team to, do good estimates. Don't make them do it. So. I i think that the most important, thing i say to someone in the team first of all is. Understand. What is being asked. Um, i think it's. Probably the number one reason why. You give wildly, incorrect, estimates is a misunderstanding, of what is actually being asked for. Um. You're jumping into conclusions and thinking it's a lot simpler than it actually is. Um. And then you know this is less of a tip for, some of my team but actually more for, people watching as lead devs. One thing to watch out for, in your team, is um. Watch out for sort of, uh. Overconfidence. Like people that are. Just. You know that they they think they're great uh this happens more, more often maybe in. In junior people, and um. They think they can do everything very quickly, maybe they're a bit naive because they've just just joined they have they haven't realized. How long it takes to do certain things when you need to collaborate with a large, organization. In a large company. And in the amount of process around that. Um. That can often lead to, sort of. Estimates being shorter than they should be. But um. Another. Another factor i've seen you know and it certainly happened, to me as well. Is uh is imposter, syndrome can also also, um, deflate. So. You know when. You know i've joined, uh. Teams of engineers, that are all. Like, incredible, people all working really really fast and really really productive. I sort of look at that and i think you know i, i should be doing, that task as you know as quickly as they can do it right. And. I'm, you know i've fallen into a trap of giving an estimate. For. How long i think it should take me to do that task rather than how long you know, it actually will take me or how long. Uh deep down i know it will take me because i've still got to ramp up i still need to learn the thing before i do the thing. Um. So you know that i think that's uh that's a good good thing to watch out for in your team. Anything to add. Dominica. Yeah sure. Well. Estimating, is always a bit personal. Uh, sometimes, it's about, ambitions. So you really want to say, you will do it faster, when. When someone is asking. Or or you're afraid, to give, estimates. In front of team. Especially, if you're not. Seasoned. If you're a new one or a junior. Developer. You just. Want to. Do. The right thing say the right thing and not, say. What you really, feel so what you can do as, leaders, in your teams is build trust, between. All the teams member. And also the choice, between. The team, and the stakeholders. Because, the, pressure, from, the, let's call it outside, the world. Can. Make your team. Feel. Not safe to give. The estimations. They, really. Believe, in. Yeah, i definitely have similar experience, on that as well i think building the trust between stakeholders, and the team, and helping them understand their concerns, as well like and being transparent, about that was really helpful. Anything to add here daily. Well but i can tell it's, again, from my experience, uh. It helps a lot when, you have already history. Of the performance, of the team that you can use that, the methods, out there the monte carlo one it's just one of them, that can you can use that data that historical. Data. And then, you can, reach, a point, where. You don't, have to make all developers. In the team give a time estimation. For each item, you can just count the items. So, this is something that we, we, reached. Actually. And when we have a new requirement, which is count. The steps. The number of stories, or however you call them work items they need to be done to implement, that, and then throw that into that simulation, that is taking that uh input.
From The historical, data and then you you get a date you need to. To use the time to. Give a time. On your own so, this was for us, really, motivated, because we felt like it's amazing we don't have to, be, item-based. Estimates. Anymore, because we have that tool that is helping, us it's just a tool. But of course the important, thing is that a process, is continuous. You need to refine, that forecast, continuously. Because, you know. Every time. There are changes. There are maybe, hidden, uh refactorings. That we didn't know. Uh at the beginning when we counted the working items. Or. Etc. But um. My point is that there are also, ways, out there that can help the team, a team which has history, already to use that history. And to just count, the items, and you know it, gives a kick, to the teams that they can use their time better for for implementing, stuff and not for, giving an estimate. Like a continuous. Forecasting. Approach. Um, great, so we are um. Uh we got a lot of questions from the audience and i also want to give an opportunity. For me to um, give you these questions. To answer. So. Some good ones. There's, one, on, um. So for example if you charge, for your work in terms of time. In this case, how would you, um, reconcile, the deadline versus estimation, approach. Maybe danny, you have something to share there. If you charge for your time. Yeah like how do you cost. How do you manage the cost for a project, if you're, providing, a probabilistic. Estimate, to a customer. Like for example if you say there's a 70. A 70. Chance the project will take two months. So, do we charge for two months of work but how would you negotiate, that. Well what i can tell you from from. Our experience. Is that usually. We in our in our context, is that usually we get, a budget, allocated. So basically, we just have. That amount of money there dedicated. Because, we our stakeholders. Are business, units, and the in the whole logistics, concern, where i work, so the air force in trade uh road freight the business units give us the id, people the requirements, and we have to. You know, so mostly we have budget, allocated, already, so we are kind of negotiating. The scope. It's more about a scope negotiation. There, so they have to decide okay, what do what is really really really important to have ready until that date when they are given a deadline, like that, there are some other cases where they are already. Not given deadlines. So they are. Uh. Like okay give me, as much as you can. As soon as you can so, it's about that the conversation. That constantly, the project manager, the the product owner is having with those stakeholders. So we're doing that forecasting, continuously. And they are continuously. Speaking, very closely, about that so that that's how it happens in our case. Let's see, anything to add here. Um. Yeah, another, question is how do you estimate when it's not clear which developer, and hence their skill level will be responsible, for the implementation. Oh good question. They. Um. You know as doing the work should provide the estimate. Uh if, possible. Um. But you know so going back to what i said in my last point that's. It's, it's all about, um and you know, dominica, touch on this as well. Having, um. Uh you know a culture. Where you have trust, between, between teams and, uh. Those asking for the estimates. And, you know whether, there's a lot of respect, and people are humble. I think um. Puts you in a better place, uh for one person in the team to say, all right this would take me. Two days. And, someone else to say this is gonna take me four weeks right for the same thing. And for people to be okay with that and i think, providing, that. Environment, is the most important. Thing. All right another question how would you go about estimating. When you are required to use a technology, that you're not familiar with. I did, that. So, uh. Again, i call this buffer but, you can call it whatever. So, i would add a but, and it would be quite a big one. A buffer, for, getting to know this technology. And. Depending, on. How. Skilled. Are the people, who are going to do that. So. Do they, have like a, broad, uh.
Group Of technologies, they know or. Are they. Uh. Used to working, on different. Different things, or, are they just junior, they just know one. Programming, language, and they need to, dive deep in some different things, so, it, for for someone, who works. Across, a lot of technologies. Looking into another one may not be that big issue but for someone who always work with some one thing now changing to another is a big issue so, i'd be. Clear that, okay, we don't have competence. To work on this now, we can, gain them but at a cost of time. I could add there which is actually more general than just just this question but um. I'd give the advice, to, get involved. As early as you can in the project. You know you don't need to wait until, the requirements, are signed off to, start doing some valuable work and that can include. Figuring out how some technology, works, building. Prototypes. Proof of concepts. To sort of. Give yourself a better idea. When you then come to need to estimate, on those requirements. Uh you'll have. A better understanding, of, what you need to do at that point. All right. One question is. An audience wants to hear, anyone's, opinion, about no estimate, is that. Realistic. Politically, correct. Answer. Would be it depends. Because. Personally, i don't believe there is a, hard, uh, separation. Between. No estimates, at all or, the best estimations. In the world because it depends, on manufacturers. On the context, of how well the team works together, how about, the the technological. Expertise, like we were just saying. If we have to include time for proofs of proof of concepts. Or and so on and so on. So i believe in its most, it's, it's most important, to, first of all. Know. What is the decision, that our estimates. Are contributing. To, what what, what what's the decision that's been affected, by the. Value. That is estimated. If, no. Significant. Or or, reasonable, decision, can be found, then, uh, it's a sign, that. Uh, an estimation, would be waste, waste of time. But, uh, on the other hand if, yes, then of course it helps also to give more context, to the team to, to they understand, better, what are this what's at stake. With that estimate, that they're giving. So my opinion, is no estimates. At all. It's not, really, something. I don't believe in that approach, if you ask me, no estimates, at all there will always be some kind of estimation. At least, even in our case that we are not giving, time, the estimations. For items, anymore, but we do we still estimate. The amount of working items. It's still an estimation, because how could you possibly know that it's exactly, that what is, needed to be done so. That's my opinion, is that no estimate, is. It's a lie. Very quickly. I am i'm really glad that someone asked this question though because uh it is it is a question that comes up and, you know it's it's it's a good point right like uh, people say. Software engineers. Right we work we're working on really hard problems we're. Extremely, talented people. And, we're basically changing the world with what we do right so why. Why, keep pestering, us asking how long it's going to take. Um. So. I pre-empted, this and i looked up a, couple of examples, um. Did you know that michelangelo. Was asked for an estimate uh for the completion, of the statue, david. Uh because, it was originally gonna go on the. Um, the roof line of lawrence cathedral. And lots of other statues were gonna be there and if, if they didn't have an estimate, uh or we got it wrong it would have delayed the completion of the whole cathedral. So. Um. You know we're all very special people but everyone. Everyone is. You know an estimate is always useful nonetheless. That's great, yeah. Um, there's another, question i quite like how do you manage the balance, between. The higher, level estimates. Like the broad. Definition, of like you know t-shirt sizes. Compared to the fine-grained, estimations. Um on the feature when you start working, on it. I'd say. Depends. On what your team needs, and what your stakeholders. Need because, if you have a. High level of trust, and, highly, educated. Stakeholders. And very, experienced. Team. You just go what works. Best, for them, for the engineers, and the stakeholders. Understand. That. But, if you work with. Inexperienced. Team for example. And. For them it's easier to grasp. This detailed. Points for example. Because otherwise, they can't. Imagine. How to describe, the task or how to, divide, the task. Then, it may be, more useful. But i found it also that, for, uh. Stakeholders. Who are not familiar. With. Uh. The concept, that for example. If you use points, they are not exactly, like timed, boxes. It might be easier to use some abstract, like, t-shirt, sizes, or even, totally. Not sizes, but i know i i heard about using fruit.
Or. Uh or. Marking. Features. With, like gold. Golden, silver, platinum. And, and the team declared, okay we will deliver, one golden, item every day every sprint for example a scrum, approach. So if you have uh. Stakeholders. Who. Need some. Abstract. Uh. Way of of, talking about, these estimations. This this makes. A lot of sense. Right. Uh, one question, here um. When we're solving a problem, of estimates. It's the delivery, of the future. And the happiness, of the stakeholder, is the most important part for. Each of you. Yes. Ultimately, that's why, that's why we come i was gonna say that's why we come to work every day i'm just still in my bedroom but, um, this is uh, this is why we're. Why we're building, every everything we're doing right it's for the user right so, so um. Yeah if if you're one week late but it it didn't impact, uh. The use of that that's that's fine equally. If you're, one day late but there was a huge impact to the user that's that's, right. Let's see, yeah. Yeah, uh. Yeah user happiness, but also, in some. Part uh team happiness, i mean if user is happy what he got but. Uh we have, technical, debt, it's it's not what what we want to work for. And danny, anything to out. There. Yes well um. Actually. The best answer, in my opinion, is yours i mean, uh yes. Clear yes loud and clear yes. The most important for us is our users. Customer, satisfaction. Because uh. What are, what, why are we the product for if it's not for the customer, right. And yet. There are some contexts. Like in, mine. Where. Uh. At some point. Yeah let's say sometimes. It's more important. That. Our teams, are more predictable. Than. Our teams here fast. Even though for the user it might, mean that something, gets delivered, a little bit later, or, or you know the customer, satisfaction, gets a little bit uh. Affected. Let's say. But, this predictability. In our context. I would dare, to say it's even the most, important. Factor, because. There are so many. Planning. Uh, projects, planning, plans from different. Business, units, connected, to each other. That when, when we from the iit. Can can. Deliver, a reliable, can be reliable, on the dates that we, name. It's it's even most important, because, uh it you know, builds that trust.
With Our stakeholders. And. It, allows you know the so of of more. Yeah features, and money to build those features. And and, so. That's the reason why we have uh. Also, taking, more, disadvantage. Of. Taking, more. The advantage, and disadvantage. Of this. Forecasting. Approach, because, it kind of, helps with our credibility. On those dates that we are delivering, on our forecast, so, sometimes, there might be some scenarios, where that predictability. Is more important, and when the teams know that it can also help them to you know get a little bit, relief, of pressure. So i imagine, startups, probably is different. As you know you gotta deliver, very fast, to get time to market as fast as possible but. Yeah. That's that was my, oh. Oh, i'll just caveat the initial one word, okay, uh the answer, that's yes but yes over the long term right so, you might need to build some infrastructure, or something in the short term that will delay. Something for the user make things worse for the user in the short term. But if it's if it's improving things for the user in the long term. Then. All right yeah thank you all uh, so, if you have one. Sentence, to sum up the takeaway, for the, uh audience, how would you. Uh what would you say, maybe start with uh. Admit. Um. In one sentence i'd say. Solving estimates. Uh. It's it's a problem, of, people, not process, um. You know the important things to get right are. Humility, respect, and trust in the team and creating that environment, where people can estimate. Uh and and feel, safe doing so. Um you know beyond that, um, make sure you set the expectation. That it is an estimate, it's subject to change. Right so um. It's not fixed, and, communicate. Communicate progress along the way. Right. Dominica. Uh okay, often, the biggest value, we gain for estimating. Is not the estimate, itself, but the conversation. We have about times probe and priorities. So. Choose whatever works. Well for your company. Your team your people, and your project. And talk to people, about time and priorities. Talk and talk and talk. Danny. Yeah from my side i can only, add to compliment, from from my colleagues nika and amir, about that monte carlo method. Google, it take a look at it and it's worth it this probabilistic. Approach, it can bring up our benefits, to your team believe it or not and uh. Yeah, i'll put some resources. About that on the slack later on or if you have any more questions later, just i'll be around. All right thank you all and we'll be moving over to the estimations. Channel so talk to you. Then. You.
2020-08-25 21:26
