When we talk about a project being ‘Agile’ and using ‘Scrum’ we are not only talking about the specific Agile Development methodoloy, we are also talking about accepting change in the project. It's a given that requirements will change over time as parts of the software are built and demonstrated. Fixing the scope early on will increase the cost of making changes later in the project.

An Agile development approach remedies this by removing the idea of a fixed scope. Instead a ‘product backlog’ - a list of features prioritised into orderof importance - is owned by the client. The developers then work down this list in a structured way with constant feedback. The product owner (client) can then add or subtract features and reprioritise the backlog once they see the software working, or to ensure certain features are included with an upcoming release.

Everybody wants a fixed price estimate with a commitment on critical functionality.

We have found the best approach is to agree a ‘Minimum Viable Product’, or MVP - the bare minimum functionality with which the software can ‘go live’. During the life of the project some things will be easier and some things will be harder. Through continuous feedback it is possible to include new features and reprioritise existing features without increasing the costs.

These are the steps we take to engage with a client project:

Requirements analysis and estimate

We meet and discuss your business objectives and what you see as the product feature set. A subset of this feature set will be the ‘Minimum Viable Product’ or MVP. This is the minimum functionality the project can go live with.

From this we will produce a ‘Terms of Reference’ which will form the high level plan around the delivery and will enable us to provide an estimate and timeline for delivery of the MVP.

Assuming the MVP is a fraction of the budget available, further functionality will be developed once the MVP is delivered.

Product backlog and user stories

The requirements are translated into granular ‘user stories'and arranged into a priority order in collaboration with the client. A user story is a very simple sentence or two about the requirement in the form of :

‘As a <user type> I would like to <perform activity> so that I may <accomplish something>’

This brevity prevents getting caught up in detail before it's necessary and demands that the developers talk through the functionality with the client so we get it right. This is what makes it Agile, the ability to react to change at any stage of the project.

For example where the requirement is ‘Enable customers to email us for further information’ the equivalent user story looks like:

“As an anonymous user I would like to use an email form to enquire about a particular product so that I may receive more detailed information”

“As a registered user I would like to use an email form that is prepopulated with my data so that I may receive information about a particular product tailored to my account”

This enables a mutual understanding of what the website or application should do without nailing down every tiny detail before we start working on it.

Iterate

We operate a system of short ‘sprints’. This is time boxed so the development team will choose a subset of the requirements from the product backlog in order of priority that they feel can be delivered as working software in the sprint. Each sprint is typically two weeks long but can be changed to suit the project team.

Sprint planning

• At the start of each sprint the project team will choose line items from the product backlog that make sense to work on and commit to delivering that functionality.

Build

• The software is then built and tested. The project team meets every morning to provide continuous feedback

Demonstration

• Once complete, the new features are demoed to the team and the client

Sprint retrospective

• What went well? What can be improved? The lessons learned are captured and fed into the following sprint, continually improving the quality of delivery

These cycles iterate until either all of the backlog is delivered, the budget is depleted or a deployment deadline arrives

Launch

The development team will deploy the software into the live environment and provide storm support.

Continuous feedback

Once the site is live we can provide consultancy around analytics and the lifecycle of the appplication in addition to how well your site is doing and if anything needs to be improved, removed or reprioritised. If some features didn't make it into the first cut then work can begin on building those new features and pushing to live as soon as they're ready.