While I was reading I was just crossing my fingers hoping you weren't going to favor estimating by hours.
I'm relieved.
I agree that point estimation might be bad (most probably used very bad as everything in software development life cycle) but hour estimation is worst.
I agree that point estimation and velocity will be misused by PMs, POs, and everyone who is managing the project.
I agree that setting a deadline and scoping work to meet the deadline is ideal. This is the whole stuff Basecamp sells in their books: Getting Real, It Doesn't Have to Be Crazy at Work, Shape Up.
Define work for a given amount of time/weeks/date and set in stone the things the team could be able to work on AND remove stuff that isn't important or that won't be ship.
Chop that scope!
In the other hand, the thing with estimations is that people do not really understand what it is. According to "Software Estimation" book, there's a misconception between "Estimate" and "Commitment".
When PMs ask for an estimation of when something will be done, they do not want to know the effort but when it's going to be delivered.
Estimation: this will take 3 months to be done. Commitment: but if we only work in these two features(nothing more), we can release it in two months.
In the end, story points are a way to measure effort which will never say when something will be done but how complicated something might be.
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.
I have to disagree that I agree(?)
While I was reading I was just crossing my fingers hoping you weren't going to favor estimating by hours.
I'm relieved.
I agree that point estimation might be bad (most probably used very bad as everything in software development life cycle) but hour estimation is worst.
I agree that point estimation and velocity will be misused by PMs, POs, and everyone who is managing the project.
I agree that setting a deadline and scoping work to meet the deadline is ideal. This is the whole stuff Basecamp sells in their books: Getting Real, It Doesn't Have to Be Crazy at Work, Shape Up.
Define work for a given amount of time/weeks/date and set in stone the things the team could be able to work on AND remove stuff that isn't important or that won't be ship.
Chop that scope!
In the other hand, the thing with estimations is that people do not really understand what it is. According to "Software Estimation" book, there's a misconception between "Estimate" and "Commitment".
When PMs ask for an estimation of when something will be done, they do not want to know the effort but when it's going to be delivered.
Estimation: this will take 3 months to be done.
Commitment: but if we only work in these two features(nothing more), we can release it in two months.
In the end, story points are a way to measure effort which will never say when something will be done but how complicated something might be.