3 ms·

Story points to the rescue. It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work ho

Story points to the rescue. It sounds to me like you guys are estimating in hours, thus you give an 8 hour estimate, they expect something to be done 8 work hours after you started work. Everyone knows you have 80 hours in a two week period so they expect you do finish 10 of these 8 hour tickets. Compare that to Story Points. Your velocity over a two week sprint is auto adjusting for the typical/average meeting load and other interruptions. If you estimate a ticket at 8 story points and your velocity is 24 story points then everyone should expect you to finish 3 of these tasks per sprint. This is obviously all 'on average' and there might be a production incident that means this time you didn't get it all done or maybe the other way around, someone got sick and 3 large meetings didn't happen and you got a 4th ticket through. Also note that I chose 8 story points at random. 8 story points is specifically NOT to be equated with 8 hours. Story points are just uses as a relative complexity measure, meaning something with 3 story points is roughly a third as complex as that 8 pointer. Many managers and even people that claim to be Scrum Product Owner or even Scrum Masters don't really understand that.

walterlb 5y ago
How does this compare with estimating in hours, but having a realistic hourly output for a week, like say 30 hours? I've been somewhere that did this, and it worked reasonably well.
- tharkun__ 5y ago
  If you only have reasonable people around you it can work. It still has a lot of things going against it like feeling quite 'precise'. That was not the situation described though anyway. The larger the company is the more likely it will be that you have these unreasonable people around you and up the chain. Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points. Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate. Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense! Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.

walterlb 5y ago

How does this compare with estimating in hours, but having a realistic hourly output for a week, like say 30 hours? I've been somewhere that did this, and it worked reasonably well.

tharkun__ 5y ago
If you only have reasonable people around you it can work. It still has a lot of things going against it like feeling quite 'precise'. That was not the situation described though anyway. The larger the company is the more likely it will be that you have these unreasonable people around you and up the chain. Story points are not a cureall. But it can help shift the conversation even with the 'unreasonable' people that just look at the hours vs a 40 hour work week. As mentioned though it needs someone that really understands what story points are and that won't let "them" just equate story points to hours. Seen that too many times even from "Scrum Masters". If 2 Story Points always equal 16 hours then you don't need to use Story Points. Back to the preciseness. You estimated 30 hours but it took 33? How dare you! You could try and only estimate in whole or half days to mitigate. Story points? They have a built in jitter as estimates get larger. 0.5 1 2 3 5 8 13 20... Some unreasonable people will try to compute a number of hours from your velocity. Luckily it will usually at least be imprecise but really you should try to make them understand that it makes no sense to even do that. Also don't let them do math with story points. That's a try at making thing more precise again which just doesn't make sense. Jira for example only allowed whole numbers in the story point field. They were pressured by customers to allow/show floats. That make no sense! Even with story points you should only take in 70-80% of your velocity into each sprint. I usually average the velocity over the last few sprints too. It all serves to make it 'less precise feeling'. Yes that's math but the only math I will allow: avg(last5SprintsVelocity)*0.75 is what we take in. Round about, a bit more or a bit less depending on how the team feels since this never matches 100% to what's in the sprint anyway.