2

We use story points to estimate our user stories. We find that story points solve the problem of underestimating the amount of actual work which is required to complete a task, as it takes the complexity of a task into account along with the amount of work. But some team members find it hard to stop estimating in hours, especially when they are in a hurry. It's a common question to ask for the burnrate when we are having a sprint planning meeting. But since we believe that the burnrate will be more accurate if the person does not calculate his estimate based solely on hours, we want that to change.

Can someone help us with how we can make the team compare tasks and get to an estimate which includes complexity and amount of work instead of just calculating it with hours multiplied by our burnrate?

1 Answer 1

1

You can't really force people to stop doing hour-estimations in their head and then converting them to story points. I am a big fan of story points and even then I sometimes catch myself making a conversion from hours to points. And withholding the latest burn rates is also not sufficient to break the habit.

There are a few practices that are less conductive for doing an hour conversion

  1. Use reference stories. Pick one or two stories where the entire team has a good idea how much work is involved in getting the story Done. One story should be on the smaller side of the estimation scale (say 2 or 3 points), and if you choose to use two reference stories, the other should be on the large side.
    Then you start explicitly referring to those reference stories when asking the team to make an estimate. If you use this to break the habit of converting hours to points, the reference stories might be something that is not yet implemented, so that there is no chance to ask for how much time was actually spent on them.

  2. Use a dis-continuous scale. If you don't accept every number as an estimate, but only the numbers that belong to a scale with holes in it, then the people that do an hour->point conversion need to start rounding their estimates. If the scale has progressively larger gaps, then the rounding becomes more aggressive as the estimates get larger, which is also where the hours estimation tends to get less reliable.
    A very common scale is the modified Fibonacci sequence (0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100).

2
  • Thank you for your answer! We are already using Fibonacci to estimate and it sure does help! Would it help if we made for every value in the Fibonacci sequence (until 100) an example user story? Or is that just overkill and unnecessary? Jul 23, 2019 at 12:13
  • @Nick.Tramper: To do proper relative sizing, you should use as few reference stories as possible. The second reference story is there mostly because it is typically quite hard to tell if something is 4 times or 7 times as hard as the 3-point reference, so then you might shift to using the second reference with a higher point value. Using more references will probably lead to more discussion, both in establishing them and in using them. Jul 23, 2019 at 12:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.