Ok, time to speak about agile planification. Estimating user stories one-by-one is a common ( bad ) practice in many teams. What stage are you currently?
- 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.
Estimating User Stories: Agile relative estimations vs single-and-direct US estimation