At the start of each iteration we have a list of roughly estimated ideas – normally little more than a couple of sentences.

Before we can begin work, we need to flesh out what the idea actually entails.

This is done in two ways – we build “wireframes”; sketches of how we envisage the interaction between the site and the user. The important thing to remember here is that we are trying to outline the functionality, not the design. Hence the wireframes, rather than building something pretty in a tool like Photoshop.

Once we have agreed an outline of the interactions, we build a “story”. This is a document, in a specific format, that outlines how the feature will work – taking the wireframe and putting it into words. A typical story may look something like this:

Feature: logging in

As a user of the system
I would like to log in
So that I can see my stuff

Scenario: Successful login

Given a user with email address “dave@example.com” with password “secret123″
When I visit the login page
And I fill in “dave@example.com” for “Email address”
And I fill in “secret123″ for “Password”
And I press “Log in”
Then I should see “You have logged in successfully”
And I should be on my dashboard page.

The clever bit here is that this story is also an “executable specification” – that is our development team can use this as a basis for building the feature – and then test that the built site actually does what is asked. For example, if the login routine did not work then we may get the error ‘Expected to see “You have logged in successfully” but it was not found’.

Once the story has been written we may need to revise the points estimate, and in turn reschedule work for the iteration. But that’s to be expected – we’ve gone from a rough estimate to a precise one. However, unlike in traditional software development, we’ve built the estimate in the presence of as much knowledge as possible and not up-front, in the absence of what’s actually required.

Now the development team’s job really starts.

Firstly, we decide upon the URLs involved (the web-addresses). For example, should the login page be at /login or /sign-in ? This may seem esoteric but the address is actually a vital part of the user-interface of a web-application – remember that you can bookmark any page or even type in the URL into your address bar.

Then we build more specifications. Unlike the story above, these are much more low-level. A well-designed web-application is partitioned into layers – the most important of which are the “controllers” and the “models” – the models represent the “things” in your system (pages, users, invoices, products) and the controllers define how the user interacts with those models (for example, attaching a product to an invoice may be the work of the ProductInvoices controller at the URL /product_invoices/new).

Each specification tests the controller, model or other function within the code to ensure that it does what it is supposed to do, in isolation. Ordinarily we go from story, to controller specification to model specification – building other specifications for helpers or background jobs (or anything else) as we go. But this is partially a process of discovery – we are exploring the code to find the best way of solving the problem defined in the story – so we often take detours and sometimes even go down blind alleys.

The key thing is that once our story test runs successfully we know we are done. Well almost.

We then go back and make sure that the pages we have created look good – we concentrate on the functionality first, because it is the foundation for success, but there’s no denying that beautiful design complements beautiful code.

And lastly, we go back and review the code that has been written, rearranging it to make it work better if needed. Because we have a whole suite of tests making sure it works correctly, we can do this, safe in the knowledge that we will not break anything. And this final stage, technically known as “refactoring”, is the key to making sure that we can deal with future changes; we enhance the code to make it more amenable to future changes.

Why risk your investment to a process that has repeatedly failed when you can choose threehv, engineered to deal with the realities of software development.

Start your project today