Frequently Asked Questions

Contents

• 1. What’s the difference between “story points” and “hours” when estimating tickets?
• 2. Why shouldn’t you change user story points during a sprint?
• 3. What are the best techniques for estimating tickets?
• 4. Why shouldn’t we assign everyone tickets during planning?

1. What’s the difference between “story points” and “hours” when estimating tickets?

• Story points focus on size of a user story, compared to other user stories in the backlog (size may consider factors like effort, complexity, uncertainty, dependencies and risk)
  • Hours focus only on time
• Story points are a relative measure. The number of story points assigned to a story reflects the size of that story, compared to other stories in the team’s backlog
  • Hours are an absolute measure
• Story points are estimated on a modified Fibonacci scale (1, 2, 3, 5, 8), which avoids implying false precision
  • Hours imply a degree of accuracy that can be challenging to uphold in a complex, ever-changing software environment
  • When tasks are estimated in hours, estimates that are often a “best guess” may be perceived as firm commitments
• Story points allow the team to provide one estimate for each user story
  • Hours require several estimates for each role, e.g. back-end, front-end, QA
  • Hours estimates vary depending on the individual developer’s skill level, pace of work, and tendency to estimate conservatively or aggressively

2. Why shouldn’t you change user story points during a sprint?

You don’t want to affect your sprint commitment so generally it’s better not to change points or pull in more tickets after the sprint has started. The goal as a team is to get a good estimate on the work. If you are completely off on that estimate it would be good to take it to the retro to figure out what can be planned better in the future.

The other reason is that because story points are estimates there is a thought that everything will even out, if you estimate this one way too low, a couple other tickets will probably be too high. I think by not changing points mid-sprint, it gets the team in the habit of being pro-active about their work and putting more time into planning. Otherwise, if you have the opportunity to change points, it may be easier to dismiss the fact that the proper planning wasn’t done and done often enough could greatly affect project timelines and it would be very difficult for the business to know when you will actually deliver something.

We also use Fibonacci for this very reason (because it is not an exact measurement - giving room for unknowns, risk, etc). Which is also why teams should look at 3 sprint averages (or more - depending on circumstances i.e. holidays) when determining team velocity.

3. What are the best techniques for estimating tickets?

• Tasks should be estimated by the team, not an individual
  • Although the most accurate estimates are provided by the person doing the work, tasks are not assigned during sprint planning
• Select a small story and give it 3 points
  • Tasks should be small enough to complete within one day
• Each Team Member holds a full sequence of cards with the Fibonacci scale (1, 2, 3, 5, 8, 13, 21, 34, 55, 89…) hidden from view
• When everyone indicates they are ready, the Scrum Master calls “Ready, Set, Show!” … Or something like that
• Everyone shows their card at the same time
  • This prevents from anchoring (influencing others)
• If all of the cards are WITHIN three sequential numbers, take the average and move on
• Online tools to facilitate: https://planningpoker.com or https://scrumvee.com

4. Why shouldn’t we assign everyone tickets during planning?

• We shouldn’t assume that only one specific team member will do the work
• Teams should be cross-functional, so tasks can be selected for development by any team member
• Estimates are done as a team
  • To ensure we account for everyone’s skill level
  • Even if only one person can do the work, others may have valuable insight
  • Teams are more likely to admit errors in estimates in the future. An individual held accountable for an estimate is more likely to become defensive