291–300 of 420 posts
Earlier quoted context omitted.
I think you misread the part you quoted, while GP read it correctly - it's comparing outputs and outcomes, not outcomes and milestones.
No I did not. Let me quote again what I already quoted: > with roadmapped outcomes replacing planned milestones "outcomes" vs "milestones" See?
Earlier quoted context omitted.
I feel as you should be able to provide an estimate even if it something that you have not completely done before. One should spend some time to gauge how much of this new thing is really "new" and what parts should be easy to figure out. Then, try to look at resources about those unknown parts, and that should allow to provide a rough estimate. And when road blocks come up just communicate early, and then if PM/boss…
Im not a coder, so maybe the domain is different in a way i dont understand, but I agree with you 100%. Refueling nuclear aircraft carriers have projections start to finish, a half decade long. There are countless pre and co requisites with interrelated projects, not counting the mundane issues like material and manpower. I simply do not accept it is impossible to project a timeline for software. If someone stops you…
I simply do not accept that it is impossible to refuel in a week or so, assuming it's a couple orders of magnitude more complex than refueling a car.
Thats about how your comment sounded.
Earlier quoted context omitted.
> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. E…
>1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. Why can't Marketing just wait until the feature has been built to launch their campaign?
Earlier quoted context omitted.
> Even bad estimates are better than no estimates. No estimate is clearly better. Here's a common story I've seen across multiple companies. 1. Marketing management asks Engineering management how long it takes to do feature X so they know when to launch the online ad campaign. 2. Engineering management then asks potentially good coder how long it will take. Coder replies with a time and "it's just an estimate." 3. E…
Oh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.
Perhaps I've just always been extraordinarily lucky, but I've never heard the developers I work with complain about our Pointing and Development cycle (and I'd like to think I do try my best to 1) proactively ask them for feedback and 2) recognize and squelch any of my own reactionary defensiveness that comes from feedback). One thing I see a lot in the comments is about time estimates and the amount of pressure that…
For example, if you ask someone to transcribe 10,000 pages of text, and you know that they type 60 words per minute, and that there are an average of 300 words per page, then you can estimate that it will take approximately 833 hours to transcribe.
If we followed your method of estimating stories strictly by complexity, however, this is clearly only a one pointer story. After all, there is nothing complex at all about the dull task of rote transcription, and all quantities are known and established.
When people talk about "complexity" in software development, what they are really talking about is how certain they are in their knowledge about all the things they have to touch. The more things they have to touch, and the more things they are unfamiliar with, the more things can unexpectedly go wrong.
Each task should really receive two estimates:
1. How long do you think this will take?
2. How certain are you of this estimate, given all the factors you are aware of?
That would be too much work, though, so people condense this into a single point value and hope for the best.
Earlier quoted context omitted.
>That's when I knew it was time to leave that team Currently in that situation. My "agile" estimate blew up by a factor of as much as 10, just because the ask was conceptually very simple, even to the domain experts I consulted. And by bad luck the way I was implementing the story it happened that the issues unfolded one-at-a-time, rather than somewhere in the beginning where we could have broken things up into more…
In retro we would have asked 'what happened and could we have avoided this?'. Then we would have broken up the now expanded unfinished work, and asked the PM if they want to continue knowing it is 10x more work than expected. If yes, cool we pull in the tickets next sprint and keep going. If no, we wrap up anything in progress and maybe come back to it later. Shit happens. The end of a sprint is there to highlight is…
But to everyone, if management is going to beat you up with your estimates, maybe find a place where management doesn't? The pathological thing described in all of these situation isn't Scrum, Agile, or giving estimates... Its the managers who beat up employees.
Earlier quoted context omitted.
What you are describing are reasons why software engineering isn't Engineering.
Could you expound on this? I’m not saying I disagree, I’m just not sure which part of what he says disqualifies software engineering from being “engineering”
To sum up, software development requires too much trust, way more than would be acceptible in an aircraft carrier or airplane or nuclear bomb. Or refrigerator.
I’ve been a tech lead for 6 years and Agile has given me a lot of imposter syndrome because I can’t seem to make it work for me. The biggest point for our org is to cost work items and realize a consistent throughput for our team on which we can make scheduling predictions. Unfortunately my tasks tend to be nebulous. They involve investigating very large potential systems and breaking out smaller tasks, many of which…
Earlier quoted context omitted.
Oh come on. Any decent project manager understands the difference between an estimate and a deadline and plans and communicates accordingly. It's not rocket science. Stuff gets shipped on time all the time.
I want to work where you do, where friction is negligible, cows are perfectly spherical, wind resistance is never a factor, all functions are continuous and differentiable across their entire domain, and all project managers are decent.
I've been developing software for over 20 years, and I still can't estimate how long something will take me when I've never done it before. This uncertainty needs to become more than just a stick to beat developers about the head and shoulders with. Most of the time the PMs understand this, but there have been many projects where they just don't get it. I have suffered great anxiety from being forced to give estimate…