To be fair, Scrum doesn't try to capture development time estimates, only the effort needed to provide value. Work items inherently vary in size, or estimated e

To be fair, Scrum doesn't try to capture development time estimates, only the effort needed to provide value. Work items inherently vary in size, or estimated effort. However, enough work should be planned during planning for the dev team to forecast what it believes it can do in the upcoming Sprint. It's all about transparency, not adherence. That said, requirements emerge daily. Transparency is essential for honest dialogue. I agree and disagree with the notion that an estimate can only be provided after the work is done. If the work is broken down properly, you can use empiricism to get a good understanding of what is needed based on previous, similar work completed. But to think an estimate can only be provided after the work itself is done is kind of ridiculous. If you section off variables with manageably-sized work you should have a good understanding of what's needed to pull it off.