- My team doesn’t use Story Points, we still estimate in man-hour, and we plan our week capacity to be 40 hours / week / developer.
- My team doesn’t use SP, we estimate in ideal man-hour, therefore we never try to commit to 40 hours / week / developer , as we recognize that our estimations are not accurate.
- My team defined what we consider 1 SP, by assigning a relationship between time and SP. As we know how long time takes each one of them aproximately, we evaluate any new US according to this measure, just multiplying the values.
- My team agreed in the shortest US that requires all of the different profiles to be delivered, and defined it as 1 SP. Did the same for the biggest , and proportionally assigned a value. Meaning, if it’s double the initial one , it would be 2SP , if it’s like 5 times, it would be 5 SP . We used a fibonacci-like approach. From this moment, we estimate every US by just comparing it to the rest of US already estimated: “Is this new US bigger or smaller than that other US estimated in 2 SP? is it smaller than that other one estimated in 5 SP ?” My team follows this approach for every new user story to estimate.
If your team is in stage 1-3 , you are still not using relative user story estimation.
What implications does this situation have? Well, you are not finding the real benefits of agile estimation and planning.