The idea with story points is you assign them consistently, so the team’s velocity is meaningful.
One team might deliver 30 points in a sprint while another delivers 25 and they deliver the same amount of work
Of course management want to be able to use story points for tracking, they want to compare teams using them, so you end up with formulas for how many points to assign
Of course if they score you on points, they get more points, not more work and story points become useless
The idea with story points is you assign them consistently, so the team’s velocity is meaningful.
Yep. But then we got some data and it turned out that story point estimates reliably create a lower quality velocity then simply counting tickets, ignoring their obvious massive size differences.
Any time spent estimating story points, creates negative value.
They worked well for us, we were updating a big system or adding functionality to it and a lot of the features were similar enough that we could reliably break the work down to sub-single sprint chunks and assign consistent story points to them
Though I have only been in one team that lasted more than 3 sprints relatively intact, and it’s only that team that got good at story pointing work
After learning about the above data, I asked my team to trial just counting tickets for velocity, and it also works fine.
The outcomes weren’t noticably different, so now we just don’t spend the couple hours each sprint that estimating story sizes was costing us.
My team was hesitant to give up story point estimation, because they didn’t want to give up the communication with leadership about which stories were XXL.
So we kept using the XXL issue tag, but dropped the rest of the estimation process.
One time a VP decided to jump in and be a developer and he just pointed a bunch of cards when the dev that was really going to do the work was off for the day. Obviously the points were way too low, so I just padded out the rest of the cards knowing the 7 points on the cards the VP pointed was going to be the entire two week sprint for the other dev and I’d need to to whatever else was put into the sprint.
And that’s how I found out the Product Manager was putting the points into a spreadsheet to track how many points each individual dev was doing. He was actually upset at me for doing 20 points in the sprint. Sure, I padded them out, but why wasn’t he bothered by the cards that had too few points on them? Just upset his spreadsheet was screwed up, but couldn’t be angry at the VP that under-pointed a bunch of cards.
I try really hard when I’m in a scrum master position (my position is pretty chaotic, 20k person organisation, scaled agile, “we need your x skills this program increment, please would you?”) to hide my team’s individual performance from management. Mostly because your can’t compare a system analysts numbers to a mainframe programmer to a mid-range programmer, but also if someone’s not pulling their weight I want to solve the problem within the team where we can approach it as equals before resorting to management “performance review” systems.
The idea with story points is you assign them consistently, so the team’s velocity is meaningful.
One team might deliver 30 points in a sprint while another delivers 25 and they deliver the same amount of work
Of course management want to be able to use story points for tracking, they want to compare teams using them, so you end up with formulas for how many points to assign
Of course if they score you on points, they get more points, not more work and story points become useless
Yep. But then we got some data and it turned out that story point estimates reliably create a lower quality velocity then simply counting tickets, ignoring their obvious massive size differences.
Any time spent estimating story points, creates negative value.
Sources:
They worked well for us, we were updating a big system or adding functionality to it and a lot of the features were similar enough that we could reliably break the work down to sub-single sprint chunks and assign consistent story points to them
Though I have only been in one team that lasted more than 3 sprints relatively intact, and it’s only that team that got good at story pointing work
Yeah. I used story points successfully for years.
After learning about the above data, I asked my team to trial just counting tickets for velocity, and it also works fine.
The outcomes weren’t noticably different, so now we just don’t spend the couple hours each sprint that estimating story sizes was costing us.
My team was hesitant to give up story point estimation, because they didn’t want to give up the communication with leadership about which stories were XXL.
So we kept using the XXL issue tag, but dropped the rest of the estimation process.
One time a VP decided to jump in and be a developer and he just pointed a bunch of cards when the dev that was really going to do the work was off for the day. Obviously the points were way too low, so I just padded out the rest of the cards knowing the 7 points on the cards the VP pointed was going to be the entire two week sprint for the other dev and I’d need to to whatever else was put into the sprint.
And that’s how I found out the Product Manager was putting the points into a spreadsheet to track how many points each individual dev was doing. He was actually upset at me for doing 20 points in the sprint. Sure, I padded them out, but why wasn’t he bothered by the cards that had too few points on them? Just upset his spreadsheet was screwed up, but couldn’t be angry at the VP that under-pointed a bunch of cards.
I try really hard when I’m in a scrum master position (my position is pretty chaotic, 20k person organisation, scaled agile, “we need your x skills this program increment, please would you?”) to hide my team’s individual performance from management. Mostly because your can’t compare a system analysts numbers to a mainframe programmer to a mid-range programmer, but also if someone’s not pulling their weight I want to solve the problem within the team where we can approach it as equals before resorting to management “performance review” systems.