One of the most devastating problems facing development teams is the proverbial analysis paralysis. Individuals or teams may develop a psychological barrier to working iteratively (coding even at the beginning of the project) for fear of not having designed/architected the whole project in advance of coding.
The Scrum method, however, provides a subtle and effective solution to this problem. The process creates a progression of small steps from high level to granular that eases people through the valley of analysis paralysis. Consider this progression. The product owner and team collaborate to list and prioritize the product backlog, a list of stories that describe user experience as well as non-functional technical stories at a high level. The team then periodically rates each story’s magnitude using an abitrary scale (like tee-shirt sizes, 1-5, or even the Fibonacci sequence [a la Mike Cohn]). Once stories have been selected and agreed upon during Sprint Planning, the team spends time breaking down the stories into granular tasks and provide ideal engineering time estimates (typically in hours).
During all of these steps, it should be the conscious responsibility of the ScrumMaster to keep the discussion at the appropriate level of granularity for the meeting at hand. There is a tendency for an individual or groups affected by analysis paralysis to voice concerns about very granular technical problems or requirements issues during meetings intentionally designed to focus the group’s attention to a higher level of granularity. If the ScrumMaster allows for divergent discussions, analysis paralysis may result and this subtle mechanism is subverted. Scrum avoids analysis paralysis through this progression of granularity, not merely by time-boxing meetings which is another tool that assists the ScrumMaster in marshalling focus.