In traditional software development projects, the life-cycle is Analyze, Develop, Test – first gathering all known requirements for the whole product, then developing all elements of the software, then testing that the entire product is fit for release. With successful software development, the cycle is Analyze, Develop, Test; Analyze, Develop, Test; and so on… doing each step for each feature, one feature at a time.
Walk before you run! Software development projects should be delivered in small bite-sized pieces, delivering small, incremental releases.
Advantages of this iterative approach to software development include:
- Better cost management: if you run over budget, some value can still be realized; you don’t have to scrap the whole thing if you run short of funds.
- Reduced risk: clear visibility of what’s completed to date throughout a project
- Increased value: delivery of benefits early and the ability to release the product when it’s deemed good enough, rather than having to wait for all intended features to be ready
- More flexibility: users can choose to change direction or adapt the next iterations based on actually seeing and using the software
For this approach to be practical, each feature must be fully developed, to the extent that it’s ready to be shipped, before moving on.
Another practicality is to make sure features are developed in priority order, not necessarily in a logical order by function. Otherwise you could run out of time, having built some of the less important features.
Build the features of the software ”broad but shallow” is also advisable for the same reason. Only when you’ve completed all your must-have “I Need” features, should you move on to the should-have “I would like”. Once “I need” and “I would like” are complete you can move on to the could-haves “I wish”. Otherwise you can get into a situation where your earlier features are functionally rich, whereas later features of the software are increasingly less sophisticated as time runs out.
Try to keep your product backlog or feature list expressed in terms of use cases, user stories, or features – not technical tasks. Ideally each item on the list should always be something of value to the user,and always deliverables rather than activities so you can ‘kick the tires’ and judge their completeness, quality and readiness for release.