4 ms·

I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference. I don’t think you need precise est

I disagree as when you have a team of 8 people understanding whether something is one day of work or 10 is a big difference. I don’t think you need precise estimation down to the hour, but knowing if someone can do 4 things in a sprint or just 1 is really important because people have interdependencies. I don’t think I’ve ever had arguments about estimates and it’s usually a really quick exercise of “I think this is a couple days” and others saying “ok.”

hinkley 2y ago
I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow. And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story. Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please. And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that. Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.
pyrale 2y ago
> understanding whether something is one day of work or 10 is a big difference. A big difference for what?
- prepend 2y ago
  For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.
  - pyrale 2y ago
    Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it? Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made. The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
    - prepend 2y ago
      I’m talking about particular user stories, not the overall estimate. For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot. My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
      - pyrale 2y ago
        Ah, I see. I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.

hinkley 2y ago

I've been encountering fewer and fewer small point stories of late. There's a certain amount of overhead for one story, both on the creation side and the deployment side, and that bookkeeping starts to overshadow. And on a larger team, a lot of these little things that need to be done could just be tasks rolled up into a maintenance story. Of course when I was on a team doing Kanban none of this bullshit mattered. You just put it at the top of the backlog and it got done. Quick win, instant gratification, next story please. And that right there is one of the biggest reasons Scrum is showing its age. It came into a world where quarterly milestones were the only time you found out how fucked the project is, and only then if you had a good bullshit detector. Otherwise it would be next quarter when you figured it out. It pushed that world down to two week resolution, one month to see past the BS. But it struggles to make good on reducing past 2 weeks. One week has more overhead, and forget about anything shorter than that. Also I've never encountered anyone who followed Ken's advice to run sprints from Wednesday to Wednesday, so we always get the worst version of Scrum.

pyrale 2y ago

> understanding whether something is one day of work or 10 is a big difference. A big difference for what?

prepend 2y ago
For any tasks that depend on it. If I need you to do something and I can’t start until you’re done, it’s useful to know if you think you’ll be done tomorrow or next week. That lets me plan my upcoming days.
- pyrale 2y ago
  Would you feel it fair, when you require an estimate, to have to say what decision you'll make with it? Usually, when someone insists on getting estimates, that's my way to make sure that they really need it. besides, it also helps making an estimate that won't be useless in the context of the decision to be made. The lesson I learned from asking that is 1) many people ask for estimates without a clue about what they'll do with the info, and 2) when a decision actually needs to be made, the actual question is never "will it take 1 or 10 days", but rather "will that project be done by regulatory limit", or "will it cost 50k or 5 millions". And for the 2nd point, sizing every small task and adding up usually compounds uncertainty in unpredictable ways.
  - prepend 2y ago
    I’m talking about particular user stories, not the overall estimate. For projects it’s almost always a budget issue “how much money and time does it need?” And that’s important because, like money is hard to get and $1 is different than $2M. I think the time is usually related to money due to revenue and costs and whatnot. My example was about estimating “how long to add a revert button to 5 pages” and that requires “db crud to revert stuff” so how long the latter takes affects when the former can start and if they can both make it into the same sprint. Etc etc
    - pyrale 2y ago
      Ah, I see. I've never been in a situation where adding db crud was its own user story. Usually, we group this and the button (and the metrics necessary to trask feature use) in a single item, and pair people so it can be shipped in one go.