Step 1: From Idea to Definition
Yesterday’s Approach
Traditionally, software design teams spent a great deal of time at a project’s outset specifying exactly how a product should look and function once completed.
Once defined, this detailed description was sent to the development division, which followed the specification all the way through the process until the product was finalised. An acceptance test was then performed to compare the product’s functions with the original requirements specification.
Redundant Functions
Often, this test revealed discrepancies between the end-product and the original specification. What’s more, certain functions defined in the specification and included in the product were often no longer useful to the client.
So much had happened while the product was under development – in the market, among end-customers and in the client’s own organisation – that the requirements specified for the product at the time of its completion were often quite different from those listed in the original specification.
Only 20-per-cent Useful
Not only that, statistics also show that, in the case of end-products whose specifications are decided down to the last detail at the outset, end-users use an average of only 20 per cent of their functionality by the time they are launched. Consequently, one might describe past development methods as well-intentioned, but with a sub-par result.
The agile approach to software development was born out of the need to overcome such difficulties. Basically, agile development involves working in week-long development cycles, instead of one long cycle from inception to finished product.
Initial Definition Made Agile
Even a product’s definition is now developed using agile methods, i.e. the first step in the development process is to draft an initial definition of the desired product. The documentation is then updated on a running basis as the project progresses based on feedback from the client and end-users.
User Stories
In some cases, a project’s requirements list is replaced with user stories. A user story is a typical situation in which the product is used and describes in detail exactly how the user uses the product.
User stories make it easier for everyone involved in a project to understand what the product is ultimately designed to achieve. This insight is especially valuable when a project’s specifications are somewhat ambiguous and the project team’s members interpret them slightly differently based on their past experience, roles, etc.
Another advantage of user stories is that they allow developers to immediately recognise when they have completed their task, i.e. when the user story’s acceptance criteria have been met and the desired functionality is achieved.
Read about the other steps of the development process:
