Just how far does velocity go in allowing a PO to estimate future work?
One of the benefits of having a (specific) dev team (over successive Sprints) estimate story points before sprint start and then summing the story points of completed users stories (velocity) is that the PO can use the that team's velocity to estimate how much work that team is likely to produce in the future.
Correct?
If this is true, then I'm wondering: If the PO is perusing the backlog and wondering how long it will take to implement story "foo", the PO will be able to use the team's velocity to estimate this for "foo" only if "foo" story points have been estimated by the team.
Correct?
If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?), then the PO is able to estimate the future only out that far, and no farther.
Correct?
If so, this doesn't seem like such a great benefit for the PO.
Am I missing something?
If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?)
If certain Product Backlog items were not estimated -- however roughly -- would the Product Backlog then be well-formed?
The Scrum Guide says:
"Product Backlog items have the attributes of a description, order, estimate, and value. <...> Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail."
(...) the PO can use the that team's velocity to estimate how much work that team is likely to produce in the future.
Correct?
Yes and no, this is no a golden rule that is always correct, I would say that if you will look only on that, then you can also in most cases just flip a coin and your likelihood will be the same.
If this is true, then I'm wondering: If the PO is perusing the backlog and wondering how long it will take to implement story "foo", the PO will be able to use the team's velocity to estimate this for "foo" only if "foo" story points have been estimated by the team.
Correct?
Well, can you truly map relative estimates into a determined time unit? Could a PBI estimated by the Development Team on 8 Story Points take 2 days to make it "Done" and other PBI estimated as 8SP could take less than 8h?
If the team estimates only for the number of stories likely to be pulled into, say, the next 1-2 Sprints (this is typical, correct?), then the PO is able to estimate the future only out that far, and no farther.
Correct?
Not necessarily, those thinks are only a small part of the overall picture. There are other things that you can measure that may guide you into the future with some sort of confidence.
If so, this doesn't seem like such a great benefit for the PO.
Am I missing something?
It's better than no metrics at all and it is easy to track. But it would be better to track other metrics as well, such as Lead / Cycle Time, Throughput, On-Product Index to name a few. You can also track the average amount of new PBIs that appears while the original one is going up the Product Backlog and is decomposed by the team - that might help you to assess how much hidden PBIs you probably have, and therefore any prediction based on i.e. Throughput will be better here.
Just pick some, try it in your context and Inspect & Adapt on the go. Maybe velocity will be enough for you?