4 ms·

Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is com

by tootie 6y ago

Scrum dogma is that estimates are for complexity, not effort or timing. The points you track in JIRA are meant to reflect how much of the current backlog is complete and how much is remaining. That can be extrapolated into timing but can't be done up front.

dragonwriter 6y ago
> Scrum dogma is that estimates are for complexity, not effort or timing The theory of story points (which originate outside of Scrum and are not part of Scrum proper) is that task-specific time estimates in creative intellectual work are extraordinarily unreliable and expending more effort on them doesn't improve them, but broad-banded complexity class evaluation mixed with empirical observation of the teams velocity produces time estimates that are (while still extremely fuzzy) both better and much lower effort, once you have the basic tracking in place, than task-specific direct estimates. The “dogma” you report seems like something that might be a derivative of that that has lost track of rationale and purpose, reducing it to a cargo cult practice.
- cuillevel3 6y ago
  Right, the estimates are not even in the guide: https://www.scrumguides.org/scrum-guide.html#sprint-planning https://www.scrumguides.org/scrum-guide.html#sprint-planning Planning poker and such are useful as they encourage the team to discuss differences and help identifying stories which are too large.
wccrawford 6y ago
My understanding is that for a team and project that's been going for a while, scrum points can be roughly turned into time estimates by looking at the history of stories that were rated for that many points and averaging. But that obviously won't work from the start, and it won't be accurate... Just better than nothing and (hopefully) better than what a programmer will estimate in their head. And IME, it's a lot less stressful on the programmer to estimate points rather than time.
jakubp 6y ago
If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :). If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered and planned in the second half of the actual (not original) timeline. A lot of important stakeholders are naturally only introduced into projects close to its finalization, which creates a flurry of new activity and discoveries. This makes projects late. But where that real halftime is - most people I worked with rarely know. I was no better, I also rarely knew. The only way to manage this I found was the basic rule: build, demo, decide what to do next. Don't get attached to original backlog and grand plans for the future. It won't work that way. Just build and make it work, launch ASAP, get decisions on a ~weekly basis done. Ignore long term planning. It's not helpful. Sadly, few business folks want that of course :)
- tootie 6y ago
  For one, it doesn't assume pace is consistent. Tracking velocity is part of the game too and it can vary with capacity, talent and maturity. Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.
  - jakubp 6y ago
    Agree on the second point. I tried to convince some managers and sales guys to stop giving estimates at all and build trust otherwise, didn't work :) As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.
    - tootie 6y ago
      It is if you're following agile principles. By the time you've completed a few stories you should be delivering every feature at production quality with all the automation pipeline and deployments ready. The question from that point is always did we build enough features for a launch.
Ecstatify 6y ago
Scrum has destroyed my organisation. It’s like working with zombies. How to turn your organisation into a cargo cult 101.

by tootie 6y ago

dragonwriter 6y ago

> Scrum dogma is that estimates are for complexity, not effort or timing The theory of story points (which originate outside of Scrum and are not part of Scrum proper) is that task-specific time estimates in creative intellectual work are extraordinarily unreliable and expending more effort on them doesn't improve them, but broad-banded complexity class evaluation mixed with empirical observation of the teams velocity produces time estimates that are (while still extremely fuzzy) both better and much lower effort, once you have the basic tracking in place, than task-specific direct estimates. The “dogma” you report seems like something that might be a derivative of that that has lost track of rationale and purpose, reducing it to a cargo cult practice.

cuillevel3 6y ago
Right, the estimates are not even in the guide: https://www.scrumguides.org/scrum-guide.html#sprint-planning https://www.scrumguides.org/scrum-guide.html#sprint-planning Planning poker and such are useful as they encourage the team to discuss differences and help identifying stories which are too large.

wccrawford 6y ago

My understanding is that for a team and project that's been going for a while, scrum points can be roughly turned into time estimates by looking at the history of stories that were rated for that many points and averaging. But that obviously won't work from the start, and it won't be accurate... Just better than nothing and (hopefully) better than what a programmer will estimate in their head. And IME, it's a lot less stressful on the programmer to estimate points rather than time.

jakubp 6y ago

If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :). If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered and planned in the second half of the actual (not original) timeline. A lot of important stakeholders are naturally only introduced into projects close to its finalization, which creates a flurry of new activity and discoveries. This makes projects late. But where that real halftime is - most people I worked with rarely know. I was no better, I also rarely knew. The only way to manage this I found was the basic rule: build, demo, decide what to do next. Don't get attached to original backlog and grand plans for the future. It won't work that way. Just build and make it work, launch ASAP, get decisions on a ~weekly basis done. Ignore long term planning. It's not helpful. Sadly, few business folks want that of course :)

tootie 6y ago
For one, it doesn't assume pace is consistent. Tracking velocity is part of the game too and it can vary with capacity, talent and maturity. Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.
- jakubp 6y ago
  Agree on the second point. I tried to convince some managers and sales guys to stop giving estimates at all and build trust otherwise, didn't work :) As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.
  - tootie 6y ago
    It is if you're following agile principles. By the time you've completed a few stories you should be delivering every feature at production quality with all the automation pipeline and deployments ready. The question from that point is always did we build enough features for a launch.

Ecstatify 6y ago

Scrum has destroyed my organisation. It’s like working with zombies. How to turn your organisation into a cargo cult 101.