4 ms·

Totally. Software estimates are like looking at a dungeon map where you can see the beginning and the end, but the rest of the page is blank until you've actual

Totally. Software estimates are like looking at a dungeon map where you can see the beginning and the end, but the rest of the page is blank until you've actually entered that part of the map.

lambda_obrien 6y ago
Sometimes you even fall through the floor and find a whole 'nother world down there.
- mtm7 6y ago
  Sometimes you find out that it's a Spirit Temple project and you won't be able to complete it for another seven years.
BigJono 6y ago
What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with. 95% of my teams have estimated using the 'story point' crap, or rarely in days (one in hours for a hot minute, that was a fucking joke I'll tell you what). In every single one of those teams eventually some stakeholder chucks a hissy fit because some feature they're emotionally invested in was 3 days worth of points and it ended up taking a month. If they'd measured in weeks, that blowout would have been lost in the noise of other things that took 2 weeks instead of 1, or 3 instead of 2. If they'd measured in months, it wouldn't have been a blowout at all. Which sounds like putting a band-aid over a gaping wound, but the thing is, what does your business really need to respond to on the time scale of days? The point isn't to improve the estimates (everyone should know by now that that's a fools errand), it's to improve the business response to what the development team is doing. If you're trying to decide whether to launch in 8 months or 12, or you need to time a project to some external event that's 6 months away, and your plan is to have a big "how are we tracking" meeting once a month, or once a fortnight. Then why do you need to measure in anything more granular than a month, or a fortnight? Set goals to the cadence of those meetings, try to make them as objective as possible, then hands off and go find something else to do. IME 95% of what teams (especially in enterprise) call estimates is just something for a PO or PM to jack themselves off to for 30 hours a week on projects where their input is only really needed for around 10.
- csours 6y ago
  > "What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with." I think you've kind of answered yourself here. Software development is fractal-like. The closer you get, the more complicated. If you want to estimate smaller chunks, you have to do a lot more work. At some point it's better to just start developing than to zoom in further, because at that point you're basically developing anyway.
  - k3liutZu 6y ago
    > At some point it's better to just start developing than to zoom in further, because at that point you're basically developing anyway. Unfortunately this is what management / PMO actually want. To somehow magically do the development in your head during a meeting so that you can accurately estimate some loosely defined task.
- awwaiid 6y ago
  I think of this often, and generally call it the https://en.m.wikipedia.org/wiki/Coastline_paradox https://en.m.wikipedia.org/wiki/Coastline_paradox -- in addition to perceived absorbtion for stakeholders, I think the estimators too find more details the closer they look.
- FooBarWidget 6y ago
  In my experience, people don't estimate granularly because they want to be fast. They see this activity as a chore, an overhead, and want to get it over with quickly. And planning sessions do take a lot of time even if we minimize the time it takes to come up with estimates. Sometimes, inaccurate estimates come back to bite us. So I regularly make the point that spending time on this chore is a necessary evil.
edoceo 6y ago
Fog of War in Starcraft
foo_barrio 6y ago
I've always seen it like trying to measure the length of a coastline or any other fractal curve. The more you zoom in any particular task or part of the curve keeps revealing details previously unseen.

Totally. Software estimates are like looking at a dungeon map where you can see the beginning and the end, but the rest of the page is blank until you've actually entered that part of the map.

lambda_obrien 6y ago

Sometimes you even fall through the floor and find a whole 'nother world down there.

mtm7 6y ago
Sometimes you find out that it's a Spirit Temple project and you won't be able to complete it for another seven years.

BigJono 6y ago

What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with. 95% of my teams have estimated using the 'story point' crap, or rarely in days (one in hours for a hot minute, that was a fucking joke I'll tell you what). In every single one of those teams eventually some stakeholder chucks a hissy fit because some feature they're emotionally invested in was 3 days worth of points and it ended up taking a month. If they'd measured in weeks, that blowout would have been lost in the noise of other things that took 2 weeks instead of 1, or 3 instead of 2. If they'd measured in months, it wouldn't have been a blowout at all. Which sounds like putting a band-aid over a gaping wound, but the thing is, what does your business really need to respond to on the time scale of days? The point isn't to improve the estimates (everyone should know by now that that's a fools errand), it's to improve the business response to what the development team is doing. If you're trying to decide whether to launch in 8 months or 12, or you need to time a project to some external event that's 6 months away, and your plan is to have a big "how are we tracking" meeting once a month, or once a fortnight. Then why do you need to measure in anything more granular than a month, or a fortnight? Set goals to the cadence of those meetings, try to make them as objective as possible, then hands off and go find something else to do. IME 95% of what teams (especially in enterprise) call estimates is just something for a PO or PM to jack themselves off to for 30 hours a week on projects where their input is only really needed for around 10.

csours 6y ago
> "What I never get about estimates is why people don't just reduce the granularity until they have some amount of accuracy they can work with." I think you've kind of answered yourself here. Software development is fractal-like. The closer you get, the more complicated. If you want to estimate smaller chunks, you have to do a lot more work. At some point it's better to just start developing than to zoom in further, because at that point you're basically developing anyway.
- k3liutZu 6y ago
  > At some point it's better to just start developing than to zoom in further, because at that point you're basically developing anyway. Unfortunately this is what management / PMO actually want. To somehow magically do the development in your head during a meeting so that you can accurately estimate some loosely defined task.
awwaiid 6y ago
I think of this often, and generally call it the https://en.m.wikipedia.org/wiki/Coastline_paradox https://en.m.wikipedia.org/wiki/Coastline_paradox -- in addition to perceived absorbtion for stakeholders, I think the estimators too find more details the closer they look.
FooBarWidget 6y ago
In my experience, people don't estimate granularly because they want to be fast. They see this activity as a chore, an overhead, and want to get it over with quickly. And planning sessions do take a lot of time even if we minimize the time it takes to come up with estimates. Sometimes, inaccurate estimates come back to bite us. So I regularly make the point that spending time on this chore is a necessary evil.

edoceo 6y ago

Fog of War in Starcraft

foo_barrio 6y ago

I've always seen it like trying to measure the length of a coastline or any other fractal curve. The more you zoom in any particular task or part of the curve keeps revealing details previously unseen.