Sprinting before you run

Developing app software, as you can imagine, is not a simple task. More importantly it can be difficult for clients – often on their first foray into the app development process – to visualise an app’s User Experience before it is built.

Accordingly, we’ve found that meaningful testing will only take place once clients have their own app to play with; even if it will potentially look and feel like an app already launched on our Welcome To app platforms.

Invest in stories

The process begins with a review of corporate objectives and end-user personas to create a vision. From this we develop a list of everything that the app could potentially do to meet those needs. As people think in narratives, we build this list of ‘stories’ using the INVEST mnemonic, i.e. each one is:

–  Independent – actionable and ‘completable’ on its own

Negotiable – allowance for change during development

Valuable – it delivers relevant value

Estimable – it can be sized relatively to other stories

Small – it can be estimated and planned for

Testable – what conditions/tests it needs to pass to be signed off

agile

Early working prototype

Once these stories are prioritised, a short period of work (Sprint) culminates with something tangible to test. And the quick delivery of a working prototype aids the efficient delivery of the project by allowing us to understand early on how people actually react (rather than guess how they will react) and what users really value. This ensures wasteful effort can be eliminated almost immediately before any major investment of time (and money).

Engaging experience

Of course, the content is a series of stories too. Whilst each app we develop is unique, the common thread is that our software links people and places. Emphasis is strongly placed on ensuring that the app is the vehicle for delivering rich content that will take visitors on a journey of discovery and provide an engaging and informative experience in the process. Both content and user stories are tested side-by-side.

Continuous improvement

At the end of the Sprint we analyse what has been accomplished and ask three important questions: “How can we do what we do better?”, ”What can we change about how we work” and “What is our biggest impediment”? By addressing these questions and maintaining incremental testing we can strive for ‘continuous improvement’ in each subsequent Sprint.

Get-out clause

Importantly, we also offer an important get-out clause for projects whose functionality extends significantly beyond our core software; if we get the app working exactly how you like before completing all the planned Sprints then you can call time and save some pennies too. It’s a win-win situation!