If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?
Does a Scrum team work more efficiently if we treat time estimates as a promise?
How much research (preparation, effort to understand the problem) in a story is enough to come up the right estimate?
What about unexpected technical problems (problems that can really mess your initial estimates) that come up after you estimate your work?
Estimations are not promises etched in stone. They are the best guess the team can make about the effort required to complete the task / story.
In answer to your question "as a Product owner how can I deliver my projects with out time as a reference?", the answer is that you can and should have time as a reference (i.e. you will release on a certain date). What you do not have is the exact scope that will be in the delivery.
Note that what I said is true of each and every methodology you use for driving your development. The difference between Scrum and other methodologies (such as Waterfall), is that in Scrum this fact is acknowledged, and accounted for. What you will do, as a PO, is to prioritize your scope, and make sure that the team, at any given moment is:
Having that, you can now ship, or deliver, at the drop of a hat, knowing that at any given moment, the latest build is the best product that could be shipped. This means that at the date of your original release commitment, you will deliver the best product possible.
Of course, this doesn't promise that it will consist of every story you requested of the team to develop, but you know that the remaining incomplete ones are of course the least important ones, that could easily be delivered at a later date.
Also, the estimates made by the team will be increasingly better, allowing you to have an early solid idea of what the scope will be at the end of the release. You will be able to ship a good solid product on time, with a few additional less-important features a few weeks later (you will of course be able to estimate when that will be).
As for the amount of research required - there's a law of diminishing returns in play here. If you break your stories small enough, then a little research should give you a close enough estimation. If you got them wrong, then you will amend in the next sprint and the estimates will be better. In 3-4 sprints, on average, you should have a good idea of how much scope can be delivered by the deadline (or how long it will take to complete the scope).
When you estimate story points in Scrum, you should know enough to be able to actually start writing the feature. The estimate is not expected to be entirely accurate, the whole point of Agile development methodologies is that they recognise that you cannot accurately predict how long development will take.
The stage at which you make a commitment to delivering is when you accept the stories from the product backlog into a Sprint. You are promising to deliver those stories within the sprint.
If you do make this commitment, this means you are willing to do some extra hours if it looks like you aren't going to meet your promise. In reality, some stories will take longer than you thought and others will take less time than you thought.
When the team has done enough estimating, they will get better at it.
You may also want to look at...
The Clean Coder (Book) - there is a chapter in this book titled "The Language Of Commitment" and also a chapter about estimating, which is really eye-opening.
Kanban - Kanban is more of a pull style of running development - there are also combinations of Scrum and Kanban called "Scrumban", which draw from both ideas.
No.
The sum of all estimates on each completed task in a sprint is called velocity. Velocity is defined as "number of completed points per sprint" where 'point' is the unit your team estimates in.
So the velocity lets you know how much your team can produce in the next sprint, assuming they use the same method to estimate and the team is stable etc.
And that is how you can be quite sure what the team can deliver without having to make any random promises.
Estimates of effort are a tool for forecasting. A forecast is neither a commitment or a guarantee. Forecasts are reevaluated continuously to account for new knowledge and should include possible alternatives such as optimistic and pessimistic variations.
We are forward looking in Agile. Commitments add no more value to organizational planning than forecasts.
Highly recommend Mike Cohn's Agile Estimating and Planning
If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?
You do not work with one big estimate, but with a lot of small estimates at the story level. A lot of the estimation errors at the story level average out. You cannot promise both content and date. You can, however, be fairly confident that the top of the backlog will get in a release (alternatively, have a fairly accurate - but not fixed - date at which time the whole backlog can be delivered).
Does a Scrum team work more efficiently if we treat time estimates as a promise?
No. That leads to sandbagging estimates and turn velocity/burndown charts into useless data - which prevents the team from improving.
How much research (preparation, effort to understand the problem) in a story is enough to come up the right estimate?
Depends how much you care about the precision. You can spend weeks preparing every estimate carefully, or give quick good faith estimates and hope errors average out. The first way is setting up for failure, because estimating something you haven't done before is really hard, and software engineering is all about stuff you haven't done before.
Personally, I don't think there is much benefit trying to get very accurate estimates. What I try to do is make sure the estimates are accurate enough - i.e. that I haven't missed something which might make cause a story to deviate from its estimate by an order of magnitude. (See next point).
What about unexpected technical problems (problems that can really mess your initial estimates) that come up after you estimate your work?
Small iterations. Ordered backlog. Small stories. The dangerous stuff is what you don't know you don't know. Lack of expertise on a problem will result in poor estimates, but you can adjust by either acquiring expertise (more elaboration) or go with 'good enough' estimates - it's all about risk management.
If an estimate is not a promise then as a product owner how can I deliver my projects without knowing how long it will take?
This is one of the biggest misunderstandings about Scrum. The question of "How long will my project take?" assumes that you can define, at some point in time, exactly what the project will entail in order to complete. But the whole idea about Scrum is that it acknowledges that the things that you learn about a project, as you work on the project, are going to change the definition of the project.
The most common way to define a project is to list the features it will have. Typically, a project is completed when all of the features have been implemented. But what if, as you work on a project, you realize that 5 of the features identified at inception aren't going to be needed, but there's 7 features that people thought of in the first 6 months that really should be included? What does that do to the question of how long it will take?
Another factor is that the things you learn will change your understanding of how to implement certain features, and as you get closer to implementing each feature your estimates are going to change. Personally, I'd resist putting numeric estimates on anything not approaching the horizon of being implemented - maybe using descriptive estimates like "tiny", "small", "medium", "large" and "huge" or "epic". Then you're not implying an accuracy greater than you're capable of estimating.
Truthfully, "How long will it take?", isn't answerable any more than, "What will it be when it's done?". Accountants and traditional business people hate this, which is why it's very hard to move away from Waterfall in some organizations.
It's also why you need to take a lot of the talk about velocity and metrics with a grain of salt. Software projects have a kind of Heisenberg's Uncertainty Principle built into them, and if you spend too much time fine tuning measurements you're just going to end up with extremely precise nonsense.
So no, an estimate isn't a promise. It's an estimate. The "promise" is the commitment the Team makes to complete a certain number of features or stories in a particular Sprint.
The estimates need be just accurate enough to allow the Team to identify how many features (or stories) they can fit into a Sprint snugly. Even more important than accuracy in the estimates is consistency, because the Team will learn how much work worth of estimates they can fit into a Sprint, even if the actual work turns out to be usually twice as much as they estimated. As long as it's consistently off, they'll be able to plan.
