Michael Sync has a question about how to estimate large projects or large features:
I heard that we should not estimate more than one or two sprints because we will have to change them later. But it doesn't really work in reality. We need to estimate the whole project or a few features in advance so we can negotiate the target date and adjust/prioritize the features. In order to estimate more accurately, we need to break down the user story into the task before creating the sprint. How should I handle or estimate for that?
Peter Bell makes an important distinction between estimates and commitments:
Are you being asked for estimates or for commitments? An estimate is an educated guess based on the information currently available. Estimates are always either high or low, and usually low when building complex software. They are not commitments and can't be used as commitments.
The consensus of the Scrum Development mailing list seems to be that project effort estimation isn't a particularly useful activity, or one that you should spend a lot of time doing. "woynam" writes:
Organizations that really get this stuff stop worrying about how much something is going to cost, and shift toward variable scope work. If you know how much you are willing to spend, and how much time you're willing to invest, then the only variable is how many prioritized features you'll get for your money. The key is that if you are "off" on your estimates, you're still guaranteed to get the most valuable features first.
George Dinwiddie writes:
If your profit or loss is dependent on a precise, accurate prediction of the cost, then you've chosen the wrong product. The upside potential is too small.Often I find that the people on the top of an organization understand this, but the managers in the middle often do not.
Ron Jeffries expresses the strongest view on the matter:
Estimates are not a good thing in most organizations: they are used as commitments and bludgeons. They also lead to a mechanistic approach to deciding how much work to take on, adding up points or hours, rather than a deeper look at what the team can accomplish, and how.[...]
I recommend not estimating stories at all, beyond making them all "a couple of days work for a couple of people". That is, of course, still a kind of estimate, but not one that is easy to misuse.
[...]
I like having the team estimate the big stories in weeks, then add them up. What this will do is give a general sense of the size of the project. THIS CANNOT BE A PROMISE, but it can be a point at with you can ask the important question, which is something like: With N dollars and M months, can we get something worth shipping?