That's a poor analogy for agile. A better one would be knowing that you need to build a bridge, pave a road, and demo a building. You determine that for this s

That's a poor analogy for agile. A better one would be knowing that you need to build a bridge, pave a road, and demo a building. You determine that for this sprint, you need to build that bridge, because it's blocking off commuters and hurting commerce. You KNOW how to engineer a bridge, and you've just decided to dedicate this next iteration to doing that. Next sprint, let's say you still haven't finished the bridge...but the building that needs to be demo'd has deteriorated to the point that it is an immediate threat to public safety. So you decide to pause the bridge building and focus on the demolition. But you KNOW how to engineer a demolition. Understanding business requirements is different from engineering, anyhow. But don't conflate re-prioritizing with not knowing business requirements. Agile doesn't describe how you should do something, it just determines when you should do it.