Decrease your iteration length. – The Agile answer to how to overcome the problem of breaking down these seemingly large requirements. At first, it sounds simple, but after giving it some thought, it sounds like a Greek philosopher’s answer to the meaning of life. (i.e. Neat answer, but what do I do with it?!)

The two dilemmas that teams face when breaking down requirements are (1) a reluctance by software engineers to develop in a (perceived) less-than-efficient mode and (2) how to use multiple people in a common area of the code, where the ‘9 mothers and a baby’ theory starts to show (no pun intended). I won’t go into all of the ROI reasons to offset both these fears because they are well documented in any Agile process book; however, there are some different ways to brainstorm the large requirement question.

In general, decreasing the iteration length may be taken in its literal form. If using a 4 week iteration, switch to a 2 week iteration. If using a 2 week iteration, the team might experiment with fully accepted story cards within a 1 week iteration. Assuming the team is already using a 2 (or less) week iteration, another way to consider the breakdown is by considering what would be done if only 2-3 days were given to accomplish part of a larger task and demonstrate some progress, no matter how small. Unless the answer is ‘give up and quit’, there is some part of the requirement that can be done in a shorter period of time. As stated before, the team must trust the counterintuitive notion that this approach will not result in the most productive use of everyone’s time.

Since many problems are too large for one person to code within one iteration, it only makes sense to use multiple software engineers. One way to look at using multiple people is to consider a drastic approach of being forced to solve the problem of how to write a ‘say hello’ program with equal participation from 3 people. While a completely ridiculous way to solve this problem (not to mention a ridiculous problem), each person could rotate typing the code on a single keyboard. The point is to highlight that every problem could be broken down (components, classes, methods, etc.), and once again, the team has to make a leap of faith that the paybacks in familiarizing multiple people with more of the code and the benefits of demonstrating working software will make the team more efficient over the long term.

Last but not least, teams can approach the requirements breakdown phase as a mental competition. While many engineers like to exhibit their problem solving skills, the team can make the breakdown process a problem in itself. Peer recognition and other forms of compensation can be added to help change the old mindset of cranking out code to put food on the table. In this case, the baby gets new shoes when high quality code is delivered frequently and not when the super engineer works 24 hours straight to code something no one else understands, which will take 3 weeks to test in the quality.