When I first started working with my current employer I didn't know how to do accurate estimates. I still can't do accurate estimates now. I've been with my current employer for over 25 years.
TL;DR 32:40 Gerard beings speaking about Risk and Uncertainty Management Checkpoint Meetings between the project manager, developers and product owner (external or inrternal). There you are, you can continue your life.
West Wing fan by any chance?? :) Interesting content - I think that there are a few things that when blended together gives a sensible approach. Value based planning is a great idea; function point analysis can give an fairly objective feel for why an estimate is what it is - and that can be helpful to create a dialogue between the dev team and the business; most of all though I think it should be considered that an estimate (which is a range!) is something to be regarded as a useful starting point, to have frequent bite size deliverables (creating a drumbeat of delivery), and for the schedule to be revisited as experience is gained and learning occurs.
Hi Robin, yes the slides were presented from PowerPoint, here is a link: www.slideshare.net/gerardbeckerleg/noestimates-stop-lying-to-yourself-and-your-customers-and-stop-estimating
And terminate the contract with the person who told you to do the estimation. I met a some managers with no sense of business, doing things in the wrong way. Sometimes I wonder, how some people get into the position of being a manager, oooooh my god hahaha.....I can laugh now, but if you experience some decisions of pm's on projects, it's worth crying...
Im not sure youre getting the principials of the Scrum process right in your critics. The idea of estimating a story in an scrum process is to get an overwiev over the teams velocity. I'll give you a point were you say, that estimation is hard and its most likely your estimation will not take all your dependencies into account. But thats exaclty why its called an estimate. We're estimating because there is no human being who can get this on the mark. The agil knows that and instead of making up stupid deadlines by asking the developer how long the working process needs, scrum works with a "fictional" time measurement, the story points. A story point is something designed for your team. You speak about how its a problem doing an estimation for an fellow employee. The spirit of scrum instead is estimating the story as a group. Over a distant period of time your team will get better at estimation and your teams velocity gets more concrete. But lets try to imagine to run a project without the estimation process. The first question that comes into my mind is: "how to keep up with deadlines ?". There is no instance that determines how long your work will last, not even an estimate in fact, something wich I would describe as complete randomness and anarchy. With scrum we get some tools to support our estimations. Through small sprits we receive PO's feedback and furthermore we get the possibilitys of interaction. You can tell the PO's about your problems which can result in the PO's adapting the software requirements. It might be even rational to drop a project at some point. Thats were the estimate kicks in again. With an estimation you can at least controll your failures if theres an project very hard to estimate tell the PO and after a sprint you come to a decision about further progression. Im not trying to make my point incontestable, but I want to get into a dialog, tell me more about your opnion if you please.
Been watching the #NoEstimates videos. I always feel bad for giving wrong estimates, ever since I graduated from university. I have always looked for some senior person who can give me well defined strategies to precise estimates. Such estimates don't exist. Such senior engineers don't exist either. This is the RED PILL.
Very nice topic, but would be nicer if the guy could hold a normal voice tone and not scream randomly... Had to close the video when listening in the car due to exaggerated increase in volume in some parts of the speech :(
Really sorry about that, our latest audio processes makes sure that everything is nice and level throughout, hopefully you can enjoy our newer and future videos in the car, the same way I listen :)
Yes, focus always on analysis of what is delivered in a given time and budget i.e. effectiveness of produced to master low cost/time and to create high value. It is so simple. not sure why entire world is struggling with a managed way. I call this as #bottom-up value analysis more than #top-down estimates stupidity
Favorite #Agile video. Very prophetic and still holds up 6 years later
This is the best video I’ve seen so far on the topic of software estimation.
When I first started working with my current employer I didn't know how to do accurate estimates. I still can't do accurate estimates now. I've been with my current employer for over 25 years.
I just came across this, even though its 7 years old it's still spot on.
Good material and Well presented.
Such a unique, one of a kind session. I couldn't related more to that. AMAZING talk!
TL;DR 32:40 Gerard beings speaking about Risk and Uncertainty Management Checkpoint Meetings between the project manager, developers and product owner (external or inrternal). There you are, you can continue your life.
Best video on estimation, learned so much
Glad it was helpful!
West Wing fan by any chance?? :) Interesting content - I think that there are a few things that when blended together gives a sensible approach. Value based planning is a great idea; function point analysis can give an fairly objective feel for why an estimate is what it is - and that can be helpful to create a dialogue between the dev team and the business; most of all though I think it should be considered that an estimate (which is a range!) is something to be regarded as a useful starting point, to have frequent bite size deliverables (creating a drumbeat of delivery), and for the schedule to be revisited as experience is gained and learning occurs.
are we willing to be hired by 2 weeks basis and see how we work then extend another 2 weeks of our employment contract?
Very nice video sir..just wanted to know one thing..all the slides displayed here were displayed in microsoft powerpoint app right?
Hi Robin, yes the slides were presented from PowerPoint, here is a link:
www.slideshare.net/gerardbeckerleg/noestimates-stop-lying-to-yourself-and-your-customers-and-stop-estimating
Great content! And yes London underground is a perfect example :)
36:35 The key part
And terminate the contract with the person who told you to do the estimation. I met a some managers with no sense of business, doing things in the wrong way. Sometimes I wonder, how some people get into the position of being a manager, oooooh my god hahaha.....I can laugh now, but if you experience some decisions of pm's on projects, it's worth crying...
I have a suggestion: Let experienced people do the estimation in oppositon to people who just finished university....I think this is a good start :D
Daniel Mihajlovic yes, but then the management assigns some novice programmers to do the implementation. How much is the estimate then worth?
Im not sure youre getting the principials of the Scrum process right in your critics. The idea of estimating a story in an scrum process is to get an overwiev over the teams velocity. I'll give you a point were you say, that estimation is hard and its most likely your estimation will not take all your dependencies into account. But thats exaclty why its called an estimate. We're estimating because there is no human being who can get this on the mark. The agil knows that and instead of making up stupid deadlines by asking the developer how long the working process needs, scrum works with a "fictional" time measurement, the story points. A story point is something designed for your team. You speak about how its a problem doing an estimation for an fellow employee. The spirit of scrum instead is estimating the story as a group. Over a distant period of time your team will get better at estimation and your teams velocity gets more concrete. But lets try to imagine to run a project without the estimation process. The first question that comes into my mind is: "how to keep up with deadlines ?". There is no instance that determines how long your work will last, not even an estimate in fact, something wich I would describe as complete randomness and anarchy. With scrum we get some tools to support our estimations. Through small sprits we receive PO's feedback and furthermore we get the possibilitys of interaction. You can tell the PO's about your problems which can result in the PO's adapting the software requirements. It might be even rational to drop a project at some point. Thats were the estimate kicks in again. With an estimation you can at least controll your failures if theres an project very hard to estimate tell the PO and after a sprint you come to a decision about further progression. Im not trying to make my point incontestable, but I want to get into a dialog, tell me more about your opnion if you please.
Been watching the #NoEstimates videos. I always feel bad for giving wrong estimates, ever since I graduated from university. I have always looked for some senior person who can give me well defined strategies to precise estimates. Such estimates don't exist. Such senior engineers don't exist either.
This is the RED PILL.
I loled so hard att padding with 15%, I always multiply my estimates by Pi.
Nobody says that you need to get better at estimation if you are always overestimating by massive amounts.
Very nice topic, but would be nicer if the guy could hold a normal voice tone and not scream randomly... Had to close the video when listening in the car due to exaggerated increase in volume in some parts of the speech :(
Really sorry about that, our latest audio processes makes sure that everything is nice and level throughout, hopefully you can enjoy our newer and future videos in the car, the same way I listen :)
Thank You!
Yes, focus always on analysis of what is delivered in a given time and budget i.e. effectiveness of produced to master low cost/time and to create high value. It is so simple. not sure why entire world is struggling with a managed way. I call this as #bottom-up value analysis more than #top-down estimates stupidity
Can’t stand the slides. Just a distraction from an interesting topic.
i dont agree with this sorry/
why were you estimating in the first place if you were a graduate? Fix that and you save us 1h of talking...
Are you a software dev?