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.
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.)