Great post! I've actually been thinking a lot about story points, I was hoping to write down my thoughts as well hahaha. I do relate with a lot of points you highlighted.
I do like the idea of throw away everything that is not absolutely necessary, but the team needs to have a strong maturity to be able to follow up on these "nice to have" things that ultimately can make the difference to the end user. Otherwise, that's will always produce "half ready" projects.
One thing I've been thinking a lot is that we do story points to estimate scope and predict velocity, but ultimately the constraints are under time. The product, management, or any client theam is not interested in how many points that feature is. They are interested in when that thing will be ready.
We were thought that estimating using time/hours is bad, the good is to estimate complexity. But my impression is that this fixation about complexity just adds one more layer to the problem. That layer being to translate the "complexity points" to "time estimatives" so you can communicate to other stakeholders the when. And that is yet another place that we increase the error margin.
I've worked with various models and teams, the conclusion for me is the same: Software engineering estimates are ridiculously hard.
Or as I like to repeat to our Project Management Office - estimates are always wrong. When was the last time you got a taxi (not Uber etc), and the estimated fair is what you paid? When was the last time you called a plumber, and the quoted estimate on the phone is what you paid?
They're called estimates, because we're guessing.
To me, a developer measuring complexity is a good thing. Project Management usually aren't technical, so wouldn't have a clue how complex a bug was to fix. Planning poker solves that.
Story Points then allow a Team to build a Velocity (number of points burnt down, across a number of sprints, gives average velocity per sprint).
Knowing the Team velocity, and having a fully estimated backlog, allows a Project Manager to simply drag/drop stories into Sprints 6 months in advance if they like. Of course, the difficulty then is how to manage the fact that estimates can, and should change (as we know more about the problem later down the line).
Our software engineering problem is: How do we define Done? (I'd love it to be, it's in the Production environment, and users can hit it with a hammer... but honestly, we're not there yet for a number of reasons.)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great post! I've actually been thinking a lot about story points, I was hoping to write down my thoughts as well hahaha. I do relate with a lot of points you highlighted.
I do like the idea of throw away everything that is not absolutely necessary, but the team needs to have a strong maturity to be able to follow up on these "nice to have" things that ultimately can make the difference to the end user. Otherwise, that's will always produce "half ready" projects.
One thing I've been thinking a lot is that we do story points to estimate scope and predict velocity, but ultimately the constraints are under time. The product, management, or any client theam is not interested in how many points that feature is. They are interested in when that thing will be ready.
We were thought that estimating using time/hours is bad, the good is to estimate complexity. But my impression is that this fixation about complexity just adds one more layer to the problem. That layer being to translate the "complexity points" to "time estimatives" so you can communicate to other stakeholders the when. And that is yet another place that we increase the error margin.
I've worked with various models and teams, the conclusion for me is the same: Software engineering estimates are ridiculously hard.
Or as I like to repeat to our Project Management Office - estimates are always wrong. When was the last time you got a taxi (not Uber etc), and the estimated fair is what you paid? When was the last time you called a plumber, and the quoted estimate on the phone is what you paid?
They're called estimates, because we're guessing.
To me, a developer measuring complexity is a good thing. Project Management usually aren't technical, so wouldn't have a clue how complex a bug was to fix. Planning poker solves that.
Story Points then allow a Team to build a Velocity (number of points burnt down, across a number of sprints, gives average velocity per sprint).
Knowing the Team velocity, and having a fully estimated backlog, allows a Project Manager to simply drag/drop stories into Sprints 6 months in advance if they like. Of course, the difficulty then is how to manage the fact that estimates can, and should change (as we know more about the problem later down the line).
Our software engineering problem is: How do we define Done? (I'd love it to be, it's in the Production environment, and users can hit it with a hammer... but honestly, we're not there yet for a number of reasons.)