[tadfisher]

One way to address this problem is to not ask the question, but to work with your teams to set goals for a longer period of time such as a quarter. Then structure your organization such that it doesn't depend on the exact timing of work completion.

[cortesoft]

How does a longer period of time help with estimation? Trying to estimate what you will complete in a quarter is even harder than estimating what you will complete in a week… errors compound.

[AdieuToLogic]

  How does a longer period of time help with estimation?

I interpreted the GP's statement of:

  One way to address this problem is to not ask the question, but
  to work with your teams to set goals for a longer period of time ...

To mean, "don't focus on estimating each individual task, but instead set midrange objectives." Which contextualizes the GP's suggestion of:

  Then structure your organization such that it doesn't depend on
  the exact timing of work completion.

To imply avoid the desire to "estimate what you will complete in a quarter" and instead focus on delivering prioritized stakeholder value.

[cortesoft]

If you are setting “midrange objectives” for a quarter, you are basically saying “I estimate I will complete this much work in the quarter”, because you are estimating you can complete enough work to meet the objective in a quarter. Either the objective is easy enough that the estimate doesn’t have to be that accurate to still meet it, or the objective is not specific enough to require an accurate estimate.

I actually mostly agree with the comment I was replying to, I just think the “set goals for a longer period of time” was not filling in the whole picture. You can’t just set the same types of goals you had when you were making sprint estimations, stretch them out to be quarter estimations, and expect the problem to go away.

[AdieuToLogic]

I think the difference is in plurality. Setting goals for a quarter (or month, or year) to me is more of a team thing/focus/discussion rather than an individual's estimation of what they can do. And I completely agree with you that stretching a sprint into a quarter makes no sense if it is only for estimating one person's work.

Given that so much of what we do as developers typically depends on more than just ourself in an effort, I agree with what I think tadfisher is expressing; realistic delivery planning can be achieved by focusing on "teams and goals for the next few months" and cannot be by trying to answer "how long will <insert feature never done before> take?"