4 ms·
I'm no scrum fanatic, but there's real value in doing estimates at the beginning of work, then reviewing how long it took at the end of work (without revising e
by caust1c 6y ago
I'm no scrum fanatic, but there's real value in doing estimates at the beginning of work, then reviewing how long it took at the end of work (without revising estimates mid workstream).
The point of separating these from actual time is not to make people feel better about themselves, it's about accounting for how much unplanned work there is in your organization which is different from org to org and even project to project.
By reflecting on how many "story points" some piece of work took, then you get better at estimating how much calendar time something will actually take.
FWIW, I've never seen this work in a team setting. I use it in an individual setting where I estimate work for myself, then gauge how much I can get done in the context of a project or org.
- hrktb 6y agoI always wondered how it worked in functionnal organizations so perhaps You could tell me. We were told the base principle was to have a stable team and a stable stack, and at some point we had reference tasks to calibrate our point system. But then we had team shuffles about every 6 months ~ 1 year, so team velocity was a fantasy. Then we changed core libraries, introduced services using new stacks, built new API, adapted to other teams’ new paradigms. And all of these changes felt to be for the better to us. Everyone would have left if we kept everything inu place for the sake of point consistency. Basically, how did you deal with change ?
- loopz 6y agoIf you read your own post, for you, the answer gives itself. For managers and executives, maybe the answer is different?