3 ms·

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 w

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.

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.