user story / bug estimates

By | January 2, 2020

After creating a user story or bug the team should be included in the estimation process.

There is a great benefit to involving the team. First it allows them to have a stake in estimating their workload, but more importantly it is accurate. The reason why is because of the principle of collective opinion, also known as “wisdom of the crowd”

The “wisdom of the crowd” was demonstrated a long time ago in England.

At a 1906 country fair in Plymouth, 800 people participated in a contest to estimate the weight of a slaughtered and dressed ox. Statistician Francis Galton observed that the median guess, 1207 pounds, was accurate within 1% of the true weight of 1198 pounds.

Wikipedia

There are many methodologies out there to aid in this estimation process.

  • Scrum poker- team mates have cards in their hands and place one card on the table face down. The cards are number as follows: 0, 1/2, 1, 3, 5, 8, 13, 20, 40, 100. When all the cards are revealed a discussion is had about the results. More cards are placed until a consensus is reached.
  • Bucket System – team members place user stories in numbered buckets similar to scrum poker numbers. It starts with a random user story being placed in bucket 8. Then two more cards are chosen by random and placed relative to card 8. If these first three are skewed in a weird way they are balanced out by moving them into different buckets. Then the remaining cards are split up among the team and each member places their cards in the buckets as they see fit. After all the cards are placed the team reviews what they have done and adjusts as necessary.
  • Other variations of the two above change the numbers to sizes XS, S, M, L, XL, use real poker cards or just have low, medium, and high
  • Ordering user stories low to high in successive rounds
  • Voting

myAgileStory.com uses a voting process with the same numbers as scrum poker. Instead of using cards the team votes anonymously for each user story.

When all the votes are cast the team can see the results and have a discussion of why they voted they way they did. Votes can then be recast as many times as necessary.

Unlike Scrum poker the team does not have to reach a complete consensus and the average can be used instead. This average takes advantage of “wisdom of the crowd”. The average can then be committed to the user story or bug.

One unique feature of myAgileStory.com is that the votes remain saved for each user story. Later it is fun to see who came the closest.

Estimate voting in myAgileStory.com

When a user story is edited there is a voting button that each team member can use to case their vote.

Once the button is pressed the following is displayed. The user cannot see the other votes cast yet. The next step is to select the estimate you are comfortable and press “Vote”. You can choose ? or coffee to abstain. Be careful though if you select coffee, you might have to serve your team mates coffee for the rest of the day!

After all the votes are cast the team can see the results by pressing Results. If they want to revote they can repeat the process. Once the team is satisfied they can commit the result found. Later revoting can still occur if needed.

I like this way of estimating because the team is not pressured into arriving at the same result which is better in my opinion.

Also since myAgileStory.com is available anywhere team mates can vote remotely anytime they want.