DEV Community

Discussion on: Estimation is not impossible

Collapse
 
lsoares profile image
Luís Soares • Edited

Even if estimations are possible and even if you can get better with time, my question is why do you need them in the first place. If you work on small user stories, get constant feedback, re-prioritize daily, and pick the topmost to work on, there’s no way you’re doing the wrong thing. If things are not delivered at the expected time, estimates wouldn’t have changed that anyway because the team was doing what mattered, ir order of importance. I'm assuming the team is not putting extra hours or doing nasty shortcuts just to finish on time (my full opinion).

Collapse
 
scottshipp profile image
scottshipp

my question is why do you need them in the first place

I think that's a great question also. It is one of the questions underlying the "what even is estimation?" question. What you've said here is also something I often hear in the conversation. It shows that different people have a different idea about what estimation is necessary based on how they work. If you work in an organization that is free to "discover" the product through experimentation, then what you've said makes sense and explains why there is a segment of the tech industry that created the #NoEstimates hashtag.

Apart from that, though, I think there's maybe a blind spot in the idea expressed. Let me describe what I'm seeing and see what you think:

If you work on small user stories, get constant feedback, re-prioritize daily, and pick the topmost to work on . . .

  • What is a small user story? There seems to be invisible estimation that happens to determine this?

  • If you "re-prioritize daily" is there not estimation involved? People usually take some kind of estimate into a priority consideration. I've personally never experienced a team determining the priority of a story without an estimate of some kind as a criteria.

Collapse
 
lsoares profile image
Luís Soares • Edited

let me first state that I don't want to be extremist and say that estimations are never useful. I've been in a few places where they were not useful and it worked out fine.

regarding your points: yes, maybe there's an implicit estimation under-the-hood. but:

  • it's without with all the psychological issues (arguments, anxiety, pressure, frustration) and waste that I mentioned in my article
  • it doesn't lead to nasty shortcuts just to fulfill dates (i.e. to "please Scrum")
  • it doesn't lead to team judgement/comparison/pressure based on velocity
  • it's not used to make promises and manage expectations

also, beware that the division/slicing that I mentioned happens when kicking-off the story (or close to it); not in a separate dedicated phase (that in some cases feels a bit waterfallish).

regarding prioritization, other factors come into play, but yes, size can also be implicitly there (to recognize low hanging fruits for example), although again, not as a first-citizen but as a secondary subject.

Thread Thread
 
scottshipp profile image
scottshipp

That's all fair. There's certainly an element of toxicity around estimates in many (all?) orgs. You summarize them well.