In software development, there is a process called "scrum" — a popular sub-set of "agile" processes — where work is done in "sprints" of fixed periods, e.g. every two weeks. Each sprint should have a goal, where the goal is to deliver something to the client or other stakeholders. That something should add value to the product; otherwise, why are you delivering it? One of the benefits of this approach is that the developers can get regular feedback from the clients and stakeholders regarding what has been delivered to date, along with expectations for upcoming deliveries.
This is intentionally in contrast to the "waterfall" methodology, where development teams would work for an extended period of time, not delivering anything at all until they felt they had the whole product ready to go. The risks with such a process include delivering things that don't work right as well as things the client does not really need, while not delivering things the client needs but maybe didn't realize that until they got their hands on the "finished" product. The typical result of such risks is schedule overruns (which equal cost overruns).
For the last several sprints, our team at work have been emphasizing the need for clear sprint goals. Along with that comes an emphasis on staying focused on the current goal while avoiding distractions that should not be part of the current sprint. For example, if, while working on new feature A, a developer notices something that probably should be re-factored in feature B, it is not okay for him or her to just change gears and start that re-factoring. Instead, a ticket should be created and put in the backlog, and the team as a whole can determine during the next backlog review if it needs to be a priority: perhaps in the next sprint, or even in the current sprint — or maybe never. The important thing here is to not miss the current sprint's target goal due to lack of focus on that goal.
Our recent discussions on this during sprint reviews triggered a memory from years ago when I was in college. That memory has nothing to do with any college courses, however, but with playing wargames with my roommate. One game in particular came to mind: Avalon Hill's "Panzer Leader", a tactical simulation of World War II combat in western Europe. In one scenario, we had a closely fought battle, and I had concentrated on using all my units to their best effect, inflicting serious casualties on the enemy while holding my positions. On the final turn, my dastardly roommate realized he could run one measly little armored car unit down a side road and into a small, insignificant village. At first, this looked like no big deal, until I remembered that that little village was one of the places a player could gain victory points if he "owned" it.
That little victory point bonus was just enough to give my roommate the victory. I, however, at least learned my lesson: "Know what the victory conditions are, do not forget them, and base all your plans on them". This holds true in any wargames I've ever played, or for that matter, any games at all. In the same vein, development teams should follow the same guideline, which might be paraphrased as, "Know what the sprint goal is, stay focused on it, and base all of your decisions on it."
In fact, I suspect there is a corollary rule for most things in life where we want to achieve some sort of "victory", though we may want to be careful about focusing totally on our potential victories, as winning at all costs is not always the best way to maintain relationships and keep your life in balance.