All work needs to be estimated, not just coding time. Even talking about it before hand is part of the work. But generally many things get overestimated and many things get underestimated. But if you're in about the middle of that estimation error you can get a pretty good estimate.
Lately we've been able to do work in LESS time than estimated. But it's taken many years of polish to get there.
I'm convinced that the real drivers of success, whether a team is using Scrum or any other system -- or no "system" to speak of -- are trust and communication. If you have those things on a team that is at least competent on the average, which means you can even handle some incompetence if you have some rock stars, you'll find a way to execute that is effective for your team.
I'd bet if we looked at how your team got to the point that they can finish under their estimates, we'd find that not only does your team trust each other and communicate well, your team has gained the trust of the rest of the organization/customer and communicates your progress effectively to your external stakeholders. This results in fewer interruptions from outside.
Also, I don't really believe in "rock stars".. I believe teams are a mix of talents that complement each other. When a team does this well.. the results are good. Even if some are inevitably faster than others.
Yeah, I said "rock stars", but I really just meant programmers who are more than 1x, either because they are just crazy good or more often because they amplify the abilities of the team by being excellent library writers and support for other devs. A close friend of mine is one of the crazy good types, both skillful and fast. I'm a good programmer with a solid theoretical background, but I try to be much more in the second category of providing good support, because I'm just never going to be that fast. Sure, I can find a bug and get a patch out quickly, but I take forever to develop good, strong abstractions and libraries. But when I'm done, they'll be well-made.
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 agree. I always count it as 0.5 days no matter what minimum they put.
An important principle in software estimation is that it's better to overestimate than underestimate.
Steve McConnell's book on the Art of Software Estimation (amazon.com/Software-Estimation-Dem...) cover's this point well.
All work needs to be estimated, not just coding time. Even talking about it before hand is part of the work. But generally many things get overestimated and many things get underestimated. But if you're in about the middle of that estimation error you can get a pretty good estimate.
Lately we've been able to do work in LESS time than estimated. But it's taken many years of polish to get there.
I'm convinced that the real drivers of success, whether a team is using Scrum or any other system -- or no "system" to speak of -- are trust and communication. If you have those things on a team that is at least competent on the average, which means you can even handle some incompetence if you have some rock stars, you'll find a way to execute that is effective for your team.
I'd bet if we looked at how your team got to the point that they can finish under their estimates, we'd find that not only does your team trust each other and communicate well, your team has gained the trust of the rest of the organization/customer and communicates your progress effectively to your external stakeholders. This results in fewer interruptions from outside.
Yeah.. I can agree with that.
Also, I don't really believe in "rock stars".. I believe teams are a mix of talents that complement each other. When a team does this well.. the results are good. Even if some are inevitably faster than others.
But I like that FogBugz has the estimation process incorporated. Maybe we should have adopted it instead of JIRA.
Yeah, I said "rock stars", but I really just meant programmers who are more than 1x, either because they are just crazy good or more often because they amplify the abilities of the team by being excellent library writers and support for other devs. A close friend of mine is one of the crazy good types, both skillful and fast. I'm a good programmer with a solid theoretical background, but I try to be much more in the second category of providing good support, because I'm just never going to be that fast. Sure, I can find a bug and get a patch out quickly, but I take forever to develop good, strong abstractions and libraries. But when I'm done, they'll be well-made.