My Tips on How to Start a New Project in a way that Improves Your Chances of Success, in this FREE Guide ➡ www.subscribepage.com/new-project-guide

I once had a manager who insisted on coming to my desk with an idea for a feature or something for which a client had asked. From the very first time they did that I told them I couldn't even give a meaningful guess (and by meaningful I mean something that is not just obviously ludicrous) without more information about the idea or feature. That didn't stop them pushing me then and there for an estimate (with the false promise that they wouldn't hold me to whatever I said). Nor did it stop them coming to me and doing it again. What eventually worked was that I started responding loudly with, "One million years!". It still took three or four times, causing everyone in the office to look up and wonder what was going on each time I belted it out. I understand that managers want to know so that they can budget. And project managers want to know so that they can allocate resources. What they fail to understand is that needing to know something doesn't make it possible for the knowledge to be made available. And then, after agreeing that the estimates we give are just guesses and will always have significant margins of error, they get upset if software isn't delivered at the time given in the estimate excluding any margin of error. The only time I worked anywhere that had anything approaching accuracy in estimating was one where the task of estimating was so involved that what we did was go through the code, figure out exactly what needed to be done, down to which lines of code needed to be changed or added, what tests would need to be written and anything else that might be needed. We'd sometimes spend days coming up with estimates, coming fairly close to doing the actual work to come up with an estimate for the effort required to do the work. That company continues to be very successful in their part of the industry, but I think that it's more because the charge a lot for their software (which is very good, to be fair) than because their approach to software is good.

1) Software engineers tend to give estimates based off of an optimistic idea on how long it will take to implement something. They don't tend to factor in unanticipated problems and what it'll cost to overcome them. It's these unforeseen problems which throw estimates off. 2) Not all software engineers are equal with levels of proficiency and talent. If you take your standard developer and assign them a productivity value of 1.0 as the standard baseline, then the range of developers will be anywhere from -10.0x to 10.0x. You might ask, "How is it possible to be negative in productivity?". Some "developers" are going to cost other developers time as they need to have someone hold their hand through development, or they introduce so much sloppy work that it costs another developer significant time to refactor it. Always factor in the talents and abilities of the people working on the project. 3) I tend to look at features and try to assess if its going to take days, weeks, months, or years to implement. These are the orders of magnitude, and if you look at the problem as variations in orders of magnitude and each order of magnitude is treated as a standard deviation, then the true time cost is going to be within one order of magnitude of the estimate (with a bias towards a pessimistic estimate). If you think its going to take 1 week, it'll really take anywhere from a few days to a month to implement. 4) The other factor that's often overlooked is the organization / company which is implementing the software development. I worked at a big tech company recently and I was finding that 75% of my day was spent attending meetings. The other 25% was for actual development. I was amazed that anyone could ever get anything done. The larger your team is, and the more surface area you get with feature exposure, the amount of time spent on new development seems to decrease exponentially to an asymptotic zero. So, estimates can't be done in a vacuum because organizational dynamics will affect productivity.

"We should be, by definition, always be working on new problems." - I'm always amazed at how this confuses managers and developers. They think their job is to crank out the same thing over and over again. To which I reply, "We have these devices that are very, very good at repetitive tasks. I think they're called Computers? If a task is repetitive, a computer should be doing it."

I've made a mistake when I've once gave optimistic and pessimistic estimates - 'cause business took optimistic estimate and ignored another which led to bad circumstances and I became scapegoat. And I warned many-many times that they shouldn't rely on optimistic one. But they didn't listen So now... I don't give 2 estimates anymore - only 1 - the pessimistic one

Rule of thumb I leaned once: Take your best guess. Double it. Go to next higher unit of time. Seems to work out right for my home improvement projects.

There was a "Blondie" cartoon I saw in the newspaper years ago and didn't save. Dagwood: How long will it take you to paint these rooms? Painter: Two weeks. Dagwood: I could do it myself in one week! Painter: Are you going to do it? Dagwood: No. Painter: Well if I weren't going to do it, I could do it in three days!

I ran a dev-ops shop at ATT for 4 years with 150+ devs in four cities. Dave, I wish I could have played this video to the stakeholders every Monday morning. Damn sure would have made them sign an awk that they "viewed and understood" the content of this video.

I also use the "small-medium-large" process, usually with a multiplier upon submission :) People expect software estimates to be nothing more than a combination of known tasks, like your example; making coffee, or changing a tire, grilling a burger, etc.. - except it isn't like that. The REAL DIFFICULTY is providing estimates around a large project for an external customer, it decides whether or not you get the contract. No two companies will estimate the same, nor make the same assumptions. A naïve customer may go with the lowest bid and experience endless project change requests demanding more money, all because stated assumptions were broken. Having more experience only helps but doesn't guarantee a thing, you just have more projects to compare to. That said, if what the customer wanted already existed they wouldn't be coming to you to create something new. We've all seen and heard about very large software projects going way over initial estimates. This video is helpful to anyone, not just software developers.

"It is difficult to make predictions, especially about the future." (Various)

This was a very interesting listen. In my previous job, at a very small company, the owner was very insistent on getting estimates for entire projects at a time and was very upset if they turned out to be inaccurate but was also very upset if they were too long. Now I'm consulting for IBM, and it is as though they'd heard this exact talk some years ago and have built these ideas into their processes. You can easily guess which job is less stressful and more productive.

I recentlu found this channel and just spent this weekend to watch as many videis as I can! Being in the field for more than 20+ years already thought me about 90% of the things, though now is the time to say a HUGE thanks for validating most of the ideas I came up with and dismissing others. Every video I watched was to the point, presented with great examples and explained in a "as simple as possible" way. Thanks again here, for being a great example on how this is done! I strongly believe that everyone in our industry should benefit from the knowledge base here. Further more every C-level person(or maybe everyone in the industry) should sit back, take their time and listen closely. I do believe the content here could be a game changer and a reason for success. Thanks! (again and again)

I was often told that, as I gain experience, my estimates will get more and more accurate. Well, it's been decades now. I guess they are a little more accurate, mostly because the design I think up initially is closer to what gets implemented in the end, but I still consider myself lucky if I'm within a factor of two. Getting within plus or minus 10 percent, even in an "ivory tower" situation, is still way beyond me. I can't possibly speak for everyone but I suspect what managers are actually seeing when they see estimates become more accurate is that the people doing the reporting are learning to lie more effectively. They think project A will take 10 hours and project B will take 20, so they tell you A will take 35 hours and B will take 50. Project A actually takes only 15 hours but they still tell you it took 35 because B ended up taking 100. The other 15 hours came from working over the weekend without telling you.

The "throwing estimates" routine is actually an informal form of the Delphi method. This is one of the best ways to get a forecast from a group of experts.

As a developer I hate giving estimates, especially when I'm working on large old projects. Sometimes I have a rough idea, e.g. a week but I will use the "scotty principle" and multiple it by 4. Then when I do finish it in a week I'm a genius, if issues happen and it takes 4 weeks, they (I told you so)... Scotty Principle is from Star Trek - Scotty always multiplied by 4 when Cpt Kirk asked him how long repairs would take... Great video though. Thanks!

Dave, the bad news is that despite the very "Accurate" and "Precise" facts you've mentioned, senior management and businessmen still need an "Estimate”, so, my advice, sell them an optimistic estimate (in the feels and looks), but very conservative from the inside, this is the best approach. Unfortunately, scientific approach does not apply to how most businessmen think or practice. And they are right, sometimes. You still need to have a margin for gambling. This narrow margin can make or break the company (I know), but when it works, the businessmen will take all the credit, if not, it’s the developers' fault...!

"How long will it take" was always a big challenging question for me. Damned time quotes. I do not know much about a time estimate until I start. This video got a "Subscribe" from me.

I will watch this video after first mentioning my approach. I want, from a developer trying to write a deliverable product, two numbers: an interval of time, and a probability of delivery on the end of that interval . By setting the probability low, the developer gives himself/herself increased allowance for having missed it. My assumption (good or bad) is that if the product is not deliverable at that end of the interval, the same interval and probability reapply. I do this for estimating my own time in producing something for myself. I estimate (say) that I have a 90% chance of completing this in an hour, with the thought that if I fail to do so I will have a 90% chance of completing it in the next hour. This lets me, as a planner, create a probability function over time for product delivery, and reduces pressure on my programmer to have to live up to one single number. By allowing them to choose duration and probability, they have more flexibility in expressing a commitment.

Wow I have spent around 3 hours watching this video, reading some references in the video, by making my ultimate notes. I think it's worth it because, from now onwards I'm sure I am not going to feel extremely overwhelmed after watching my JIRA dashboard every week.

I've given up estimating as the specifications changes as we progress - so it doesn't really make much sense to spend time up front. Trust is key - just work and get things done.

And ex-manager once asked me: "What's the part that you struggle the most with?" I responded "time estimation, do you have any literature or advice on that?". Then, he went "It's indeed the most complicated part of our profession. I sometimes use a simple trick: your realistic estimation times 2 (at least), or even 3 if the system is very complex or you don't have enough information". My face was like "oukey :v", but it kinda works xD. If you want to do it properly, I'd suggest tracking your time taking into consideration all possible variables. For instance, type of task, technology, complexity, unit tests, integration tests, lack of information, level of dependency from other colleagues and teams, etc.. Also, the number of interruptions (meetings, etc.) or level of insulation from distractions (colleagues interactions, noise, etc.), and even your physical and mental condition. There're already apps and tools that could be integrated in order to apply time estimation formulas.

15:50 "..is an exercise in learning and one of the things we learn as we proceed is what the target actually is" Now that is PROFOUNDLY accurate

I fully agree with the stated impossibly of estimation. Even SP is of limited value. S/M/L is about the possible precision. Unfortunately this leads people to insist that you can’t plan what you want to make in any detail

What other 'software project management' questions would you like to see answered on the channel? LET ME KNOW 👇

Only one problem ... We are forced to make the estimate anyway. Sales wants to sell projects and customers want a budget proposition. No two ways about it really. On top of that, you're never just the only one bidding for the project. So you simply will not sell 'we shall see when we get there' when the competition is like 'gimme 50 days'. Even on internal projects management always requires an estimate. Yes ... They really are the bane of any software development team.

You understand how it works and you say it. What you are saying is the obviousness I have felt in my bones for 25 years of work, but so much misunderstood by business. I wish my bosses would pass exams on what you say. I want to work for you, be my boss :)

Manager:”how long?”. Me:”I don’t work with deadlines”. Manager:”then maybe you should not be working here”. Me:”way ahead of you”.

Thank you for this summary. There are many good ideas but what was left out are the real world problems. You said you estimate only, if you are forced. But being forced to estimate complete projects is common because managers learned it that way and customers require it. The question is how to resolve this natural conflict. You cant say "don't estimate".

Keep up the good work, I love your videos. By far the most accurate representation of real world development.

This is the best channel on KZfaq for software developers

Great video, I tend to work more on the infrastructure side of a software company so it is always important at the very first conversation to get as much info as possible so I can hold them to it without "scope creep" becoming an issue. It becomes a fine art after a while. I also have that t-shirt!

When I free lance I tend to estimate and educate. I have a previous background in global business supply chains and was at a director position before I stepped down to fully dive into app/api engineering. If the potential client is essentially a start-up, I tend to speak in terms of sunk cost, opportunity cost, MVP, and risk/reward potentials: since that's the language they understand. They don't understand dependency inversion and creating proxies and have no intention of learning the concepts. I will happily give them the reality of how long a project could take based on known knowns, known unknowns, and unknown unknowns in terms of cost and talk about budget. If I can see myself EASILY (keyword) hitting that budget with dev time, I'll let them know that upfront and help them avoid a business-killing decision where the risk far exceeds the reward. It takes good communications skills to establish trust to get as close to the real numbers as possible, because the first budget they tell you is a lie when their defenses are up. I'm sincere in wanting to protect their business and not unfairly enrich myself at their expense. I can guarantee this is much harder to do with larger projects as a member of a team without access to financial data. Besides, there's too many hands in the cookie jar to figure this kind of thing out with any kind of real accuracy. I'm curious how different companies manage their projects' timeline goals and budgets for core and desired features. My guess is, from my experience, they don't and essentially have no idea what's going on. That goes into another topic of the systemic failure of properly knowledgeable managers and visionary leaders. It's rare. You care more about them than they do you and their own business, and they exploit it.

Best summary on "how to estimate" I've come accross so far. Thanks for sharing !

Excellent talk. Thanks again. I'd like to suggest a few related matters that you might want to look into as well: The relationship between software cohesion and coupling with the ability to estimate large systems. The effect of integration (people and components) on estimations of large systems. The identification of critical paths of dependencies of both tasks and the people executing them (TOC throwback).

I got super super excited when I heard the name Steve McConnel, the author of my all-time-favorite programming book: Code Complete. I'll start reading Rapid Development ASAP.

Never give a casual estimate to answer the question "When will it be done?" Any answer you give, no matter how conditional and off-the-cuff will be taken as a hard deadline by people who see your task as yet another empty checkbox in a long list of checkboxes. If someone is asking you to estimate something complex and expecting an on-the-spot answer, you're already in a precarious position. It means you haven't educated them on the nature of your work. It's OK to refuse to answer. As much as it pisses them off, it will piss them off FAR LESS than giving an under-estimate and causing project slippage, regardless of how hard you work. I had to learn that the hard way earlier in my career. No one cares about heroic efforts which miss an unreasonably low project deadline estimate (especially if you quoted it yourself). It's always seen as a failure. Much better to give phased target dates for pieces of the deliverable and adjust subsequent targets if any previous targets slip.

What is typical or good value for a team's velocity volatility that you have seen? To make sure our definition of volatility is aligned: volatility = stdDev(of: velocity, over: 4+ previous iterations) / expectedTeamVelocity. Example: my team has an expected velocity of 7pts, their observed velocity has a standard deviation of 2pts when looking at the last 4 iteration's velocities. So their volatility would be: 2pts / 7pts = ~28%. In my limited experience of teams that actually bother to measure and quantify such things, this is the best value I have ever seen. Most teams are in the 40-60% range. I hope I'm not so late that you won't see this question, I would love to get some thoughts about where you think 28% sits even if that comes with all kinds of assumptions. Love your content! Without fail you are able to clearly articulate something about software engineering craftsmanship that I completely agree with and couldn't say better myself! My co-workers and I are a small fan club of yours.

It sucks I didn't have you as one of my CS teachers.

the trick here is to manage expectations. so also to tell the client/manager what they get with the budget and timeline they offer. so tell them the truth. or else you will have to meet there expections which will be very hard to meet.

Yes! I am an electronic hardware engineer and have been designing high technology products with HW, FW and SW for a long time. People try to do what I call "Estimation by Synthesis" where they break stuff ddown and say "That bit will take 2 months", etc. This gives hopelessly optimistic estimates. I do "Estimation by Analysis" where I try to find a recent project that is somewhat comparable and use that as a gauge - multiplying and divivding to allow for differences. This usually gets within a factor of 2x up or down, compared with >5x for the synthetic estimate! Syntehtic estimates usually need to be multiplied by Pi to improve them... :) Estimating a whole SW project by creating stories and scoring them is totally fatuous, IMHO. It is completely against the principles and ends up with a hopeless estimate.

One of the most valueable video i have watched in youtube so far. Love this guy.

I've used function point analysis a few times and it worked for me. Overtime you can fine tune the function point weights to get even better estimates for your specific environment.

I find that the best way to estimate is to forget all specific details of the current project/task and to think about similarly complex and small/large tasks/projects in the past and how long those took. Then just take the maximum of those previous ones and that will be a fairly good estimate. If you are doing something genuinely unlike everything you've done so far then ask people who have such experience. The beauty of this method is that it does not rely on any specific project details. Of course the aim here is a ballpark estimate - 1 man-day vs 10 man-days vs 100/1000 man-days...not an exact number of days. So in this way it is like the T-shirt size method.

90% of the work takes 90% of the development time, the remaining 10% of the work takes the remaining 90% of development time 🤣

I was brought into new to a new team and was being "forced" to estimate a large project once. The team had no history, and no one on it knew much about what all needed to be done. I analyzed the work and produced an estimate that I was very unhappy with. I told the manager "here you go but it's b*******". She was pretty unhappy with that response, and I felt bad about it. I found McConnell's 2006 Bill "Software Estimation" and it really helped frame the problem. We re-estimated and reframed the estimate with a lot of his material including the Cone of Uncertainty. It went down much easier this time. There are reasons people want estimates, and they are not terrible because they want them. And estimates do provide an opportunity for the team to understand the work. It takes time to do that though and McConnell does stress that and has a take on diminishing returns of re-estimation. Overall, for most software projects it's art not science. McConnell states this as well and does a great job at looking at the science of estimation and how it only applies to a narrow set of cases.

As à Product manager I often get to see both sides. Contract worth big money (and commission), verses fluffy specs and a “ideological” approach to estimate are Satans love child. What tended to work well was to make t shirt estimates and then ask customer to pick key ones. We would commit to those by date X. Other t shirts delivered and paid for in a soon as ready. Company got a commitment to revenue, customer had a promise of essential delivered on a certain date. Did we always get it right….. no. Specs change, surprises happen, but there was less panic and heat. It brought sales and development working together rather than beating each other up. Best day was when head of sales turned down a contract based on an estimate. Trust was key. The big fish contract we were working on came home on time.

I agree on everything you said 100% and it's very inspiring that people start talking about the burden of "estimates" - guesses as you said - to the industry. But I think it's also important to name as well the elephant in the room, the magic word that is to blamed for: Budget. This all happens because of "budget restrictions". The fact that someone signed at some point in time a paper that locks down the scope to a fixed date preagreeing everything without consulting you first, most times without even consulting other members, experience from other projects etc. And now you have to pay the price about it and deal with it however you can. Budgeting seems to me a very dated idea that cannot stand the challenges of software development. Yet it somehow persists throughout the industry as some (managers mostly) see it as the only possible tool to do business with, however catastrophic its results prove to be.

Totally agree. Broken estimates is the one of major reasons of burnout

I just "discovered" you on KZfaq Absolutely EXCELLENT (maybe it reflects what I *have* been finding on KZfaq). (I, too, have read "Rapid Development" back in the day)

This is sage advice. Listen to this man, he knows what he's talking about.

I told a group in my company that I will write an ETL tool for them and give me a few weeks. So far Im into month 3. This ETL thing is complex to write but its designed to be easy for the user. Making anything that's easy for the user, is hard for the developer.

"The hardware is mostly in place...." Classic red-flag.....

In answer to this question from a renowned slippery business analyst in my then company who always blamed the programmer. I said "well if you can tell me how many words will be in your specification" His sharp answer was "I can't tell you that I haven't written it yet.." This was many years ago before 'Drops Mic' was a thing

Great video! Recently had a conversation with a stakeholder. Was forced to give an estimate on a feature and guessed 1-2 weeks until it was in production. After 1 week, I get an email about me being late on a deadline I apparently committed to… 🙄

The lengths that we must go to for project funding and the amount of diplomacy to hide the fact that Estimating = Guessing. This is especially true when this type of work has never been done before with a team that has only just met.

This channel is absolute gold.

You are so good. I'm a complete beginner as a developer but everything you say strikes me as incredibly invaluable based on my experience in other fields. Thank you very much for your sharing your thoughts.

"How long is a piece of string?" I'll know when I've unravelled it

You're Planning is the art of thinking to reduce waste of peoples work. An estimation believe is an estimation believe for the expected conditions, which tends to be uncomplete unaccurate and change over time (changing requirements, daily learning curve about new aspects). Its like the biological brown moving: so don't estimate that an estimation continues to be accurate. Estimations approximate to accuracy when repeated for same or similar enough tasks, so you'r planning will get better if you plan the same task twice, three times, four times, ...

Estimation, like design, is as much art as it is science -- it involves being able to account for both known and UNKNOWN variables... The larger the number of unknown quantities and the greater their impact on the critical path of development, the wider the range of probability will be. The key to successful estimation is to separate the known from the unknown quantities, and estimate each separately. Due to the high level of uncertainty in some projects, we should engineer our process to absorb failure. The beautiful thing about software development is that it is not an all-or-nothing proposition. Code that is developed for one project can easily be repurposed for another, if it is documented and well-organized. Every project should be seen as an opportunity to develop a knowledge-base that can be leveraged for future development, consulting, or as a product in itself. Known Quantities should be kept to a tight budget and schedule to maximize time and resources available for unknown quantities. We should also assume that any unknown quantity will require time for additional research. Projects with large number of unknown quantities should be treated as exploratory expeditions --- you don't know what you are going to find. You may find that your original goal is infeasible. You may find an alternative goal that is even more profitable. Or, you may find that you have hit a dead-end. Again, unknown quantities mean that you DO NOT KNOW how much it will cost or how long it will take -- You are going to discover these values as you progress.. The key to a successful PROJECT in this situation is NOT an accurate estimation, but to look for additional value beside your central goal. Do not pass up platinum or silver in your quest for gold. Every challenge is an opportunity, every set-back a new path forward.

This video is so spot-on, I'll need to share this with my whole team.

This is valuable. And the format is unique. Keep it up!

I like how my manager asking me every day "how much time left", despite the fact he received storypoint estimation for this particular task just yesterday. 🤦‍♂

Estimate = guessing. Planning, researching and breaking down the features into tasks (WBS) would help with this. Ideally, the manager should sit with the developer to map out all the tasks and the scope of the project before you can assign time to each task. This should help with the estimation. The problem is that managers are lazy and think that their job is to forward emails to developers.

03:14 🎯 Accuracy vs. Precision: Focus on accuracy over precision in estimates to avoid misleadingly detailed predictions. 07:45 ⏳ Small Steps Approach: Break down work into small, manageable features to increase prediction accuracy. 12:30 🧩 T-Shirt Sizing: Use t-shirt sizes (small, medium, large) for estimates to limit precision and encourage breaking down work. 19:02 📈 Track Actual Performance: Track recent performance to extrapolate future estimates based on realistic data. 25:10 🎯 Fixed Date vs. Fixed Scope: Understand the difference between aiming for a fixed date or fixed scope in estimation. 29:45 🔄 Continuous Learning: Software development is an iterative process of learning; adaptability and flexibility are key in estimation. 32:18 🚀 Continuous Delivery: Continuous delivery allows for releasing at any time, providing freedom in development and adapting to user needs.

I'm french speaking and I just realized we're using the same word - in french - for both accuracy and precision.

Great video! Your experience is appreciated, it's great to be able to hear these broad concepts expressed by someone like you.

In my experience - 40 years of Software design and development - I can tell you that almost all projects go as follows: 1) The customer decides what it will cost. 2) The customer decides when it must be finished. 3) The users tell you what they think they need. 4) You make an estimate based on 1) 5) You start designing the software 6) The users change their mind every week. 7) The customer's project leader - who doesn't know anything about software development - asks you if it cannot be done faster and for less money. 8) Go to any of the previous steps. By the way, I am talking about global players. Thank God I am almost 68...

I had a professor that said when estimating times, take into consideration everything you know and then double it and then double it again.

I really enjoy this channel, the topics are spot on. Thanks!

My response frequently resembles something like: "It takes as long as it takes." This position makes me very unpopular.

I decide how to do it: 1 week, we decide how to do it: 10 weeks, you decide how to do it: 100 weeks, your boss will decide how to do it: 1000 weeks

I quite working with deadlines long ago, we get much better results that way

"The infinite fractal coastline of estimation", I love that term.

Oh my god. This channel is so informative and helpful. Thank you so much!!!

I think planning is about carefully choosing what to discontinue under some sh*t storm that will sure come. Great channel.

16 minutes and 30 seconds in and still no word about how long it will take to get the teleporter working. The customer or client project manager will not accept that. 😂

I love all your videos. Best source to practice interview questions

Most experienced engineers know that estimates are 'guestimates' and have little predictive value. Personally, I feel a knot in my stomach when being asked the question 'How long will it take?'. As an engineer, sec, I would gladly discard estimation right away! It is just that accountants, budget responsibles, managers, sales, consultants and customers want to have an indication. As an engineer that is part of an organisation, I cannot ignore these roles in the chain of software creation and delivery. These people need the information to do their part of the job. Discarding estimates completely is therefore not an option. The best we can do is to tell them to use the estimates wisely (and refer them to Dave Farley's video!).

Good content! And I like your explanation of precision and accuracy. Personally, my estimate multiplier is Pi. It's worked out well so far.

Great video Dave! Cheers!🎉

I didn't think I would ever say this, but his picture gives oversimplified criticism of story point estimates. In short, from data, feature drift should become part of your estimate. Let's say you want to estimate to change the color of a widget. Maybe you can do it in 10 min. If not all is wrong with your code. But that's not when the feature will be ready to ship. What's missing in this estimate is the designers changing their mind after the fact. How do you take that into account? Well, this may not be the first time a frontend feature is implemented, and in the past they changed their minds 5 times after a good night's sleep. That should give you an estimate of about 5 days, say. The major part of the described estimate comes from data about the project context and can be estimated from data. I found, that this is most often the case. One should definitely take that into account. So in practice it doesn't matter what you initially thought 5 story points mean. Over time it could turn out to be 5 weeks until the assigned feature is finally done. Well, now you know how long the project will take given the current set of features.

This is something I have been looking for a long time! Thanks for sharing your expertise

Great words. That totally makes sense to me... but not to my managers 😆

This guy is full of crazy ideas, but I'm buying what you're selling here....

Somehow I know think about estimating if I need a jacket by looking at the weather forecast. Sometimes the forecast is wrong, sometimes the sun is shining enough to make a big difference etc.

Not just the freedom, but seems the ultimate definition of Agile, that Agile seems to leave behind when not following a plan...err as it follows the plan planned out during planning. Always seems contradictory, but figured I was being daft over something I was simply failing to understand proper, but CD seems a bit more natural as the actual flow. Trying to integrate a happy union of the two as sort of Agile Alchemy a little CD a little Kanban and a little SCRUM I think we can have something nicer than each by themselves which have their points. But I ain't one to gossip... .

Another brilliant video!

So good, so concise, so on point!

im with you on the estimates. i detest the question. but what to say to the product owner who is pressuring the team for estimates in the next sprint? what to say without causing a stir? as we all know telling the ceo there are no estimates will result in "theres the door" also what if we dont have past estimates vs actuals? its not acceptable to a client that we dont know when we will deliver - does any of this makes sense?

‘Simple’ change gets me each time 😂

Aways brilliant! Thank you mr. Farley. I've been learning so much with you.

"Infinite fractal coastline of estimation" -> that's where the hammer hits the nail.

Your videos are always very interesting because you are transfering your experience from industry and are not just academic knowledge. Because in most of your videos you mention the need of continuous learning i would like to ask you to make a video about effective learning strategies and tactics for software developers-engineers.

Problem I have with CD, is customer unwillingness to accept the work continuously. They want you go "go-away" until the entire wishlist is done, then complain about the result instead of being part of the process.

the example in the beginning was so out there that I though "teleport" is a fancy term for direct connection or something.

The mortal enemy of software developers is the guy in marketing who sells features that don't exist yet. My previous employer (whom I left only because pay was not competitive) rarely set deadlines for development, and this freed us to do everything right the first time. Each developer had a list of projects, of varying priorities. If the high-priority projects were blocked, they has lower-priority projects on which to work. There was no feature branching.

If the new task is very similar to what you did last week, expect to be faster this time. Practice. And familiarity with the concepts. This doesn't apply much if last weeks project was also the same as the week before.

Cries in consulting.

This is another great video, from a great channel :)