221–230 of 231 posts
Earlier quoted context omitted.
Regarding the WWDC comment, of course an estimate was needed in the first place cause WWDC day was also the projects deadline.
Here is the secret: If it misses the deadline, it's going to be announced at the next event.
Earlier quoted context omitted.
Here is the secret: If it misses the deadline, it's going to be announced at the next event.
True. And the pressure not to do that would be extreme. So it doesn’t help the ‘I prefer not to give estimate, like Apple’ argument at all.
If the team provides an estimate that falls one month after the deadline, the pressure for them to change their estimate will be extreme as well. In reality, if management has already decided when the product should be released, they don't give a fuck about an estimate. What they're interested in is for the team to take ownership of a decision they didn't make, and that's what the estimate is for.
https://gioorgi.com/2021/estimation-rules/
And it works :)
The more uncertainty in the path, the less accuracy in the estimate. Kahnemann's latest book "Noise" provides some good background on why this happens.
Having multiple people do independent estimates and averaging them probably gives better results, and having a clear process to document assumptions and test sensitivity to those estimates can also help.
Earlier quoted context omitted.
Well said. My current rule based on experience is that estimates should only be hours/days/weeks/months/quarters/years with NO numbers. It is to give a sense of scale and effort so it could be prioritized and/or modified. If they want exact dates, then it is like you said, several days/weeks to go get an accurate date. I only wish that the sales team had to commit to closing dates the same way software teams do.
I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ... The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points l…
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
Earlier quoted context omitted.
I really like your suggestion to use hours/days/weeks/etc without numbers. A similar suggestion I read for estimating (originally outside the context of software projects) was to use numbers with just one significant digit, so your estimate options would jump from 8, 9, 10, 20, 30, ... The estimation mention I dislike the most is "t-shirt size". There is no clear relationship between S/M/L/XL. At least story points l…
The argument I've heard for T-shirt sizes is that if you go to numbers people try to add them together when that's just not how it works. I do agree that T-shirt sizes don't work that well though.
Here's my beef with estimates. I can give you a really really accurate estimate, but in order to do so we're going to have to spend a lot of time going through the request, building and verifying actual requirements, designing the solution and then validating it. The process will require dev resources, business resources and probably people from the support team and will take a lot of time. I'm happy to do it. It's a…
Without a detailed plan a lot of space is wasted and the apartment ends up less nice and you often end up reconstructing stuff (if it is small and non standard).
The process takes 10-15% of the total cost of the project. Do people want to spend that? No.