Strict Standards: EF_Custom_Status_Block_Editor_Compat and Block_Editor_Compatible define the same property ($ef_module) in the composition of EF_Custom_Status_Block_Editor_Compat. This might be incompatible, to improve maintainability consider using accessor methods in traits instead. Class was composed in /var/www/blog/wp-content/plugins/edit-flow/modules/custom-status/compat/block-editor.php on line 38
Estimating User Stories: Agile relative estimations vs single-and-direct US estimation -

Estimating User Stories: Agile relative estimations vs single-and-direct US estimation

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?

  1. 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.
  2. 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.
  3. 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.
  4. 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.

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.