The reason for picking a marathon as the specific analogy, which Scrum intended to do (but got backwards) is that:
1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.)
2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.)
3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".)
4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks.
I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints.
(ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)
1) It's a (very) long haul. Pacing yourself is mandatory. (In most of the legends of the first marathon, the runner collapsed to the death after delivering his message in Athens.)
2) It's explicitly an A to B with a long-term goal in mind. From software product idea to finished software, in theory. (This part of the Scrum analogy has largely been forgotten/ignored/killed of course in the modern view of software as a constant Ship of Theseus that is never finished and always has infinite backlog.)
3) Pacing yourself while running a marathon consists of breaking your run into smaller time boxes. Most runners do plan specific paces for different "splits" within a marathon. Some runners pay coaches lots of money to try to come up with these plans. (Again, here Scrum screwed up the analogy by using the exact wrong term, "Sprint": a short fast race where pace is as fast as possible, and no need to think about "the next mile" after the "Sprint".)
4) The type of race doesn't change in a marathon. A triathlon might make a similarly good long haul project development metaphor if you have to shift entirely different contexts every so often (swimming, biking, running), but software development doesn't (necessarily) have drastic context switches like that. "Mile to mile" ("week to week") in software development you are still largely doing the same tasks.
I kind of agree with the Scrum originators that the marathon was a good analogy for software development projects. I just wish they hadn't immediately broken the analogy by getting fundamentals wrong like the relationship between Marathons and Sprints.
(ETA: I'm not myself a runner. Most of what I know is from siblings and friends and trying to be a good sideline supporter.)