Our visual prototype and feature documentation will ensure your finished product accurately reflects your requirements

Smith & Nephew
Smith & Nephew

When we build software, we leave nothing to chance. We don’t assume; we ask, understand and articulate into an exact plan. The tangibility of this plan is the visual prototype and documentation of the software's features in plain English. This ensures that you’re getting exactly what you expected and agreed to.

The importance of planning

The reason many software development projects fail is due to poor planning. Without it, you run the risk of delays, errors and costs.

For developers, the excitement comes from getting stuck into writing code and seeing a project taking shape. As a result, meticulous planning is often overlooked with developers cutting corners and making assumptions.

Understandably, customers want their software up and running as soon as possible, so often focus on the core functions rather than considering rare scenarios. It’s not until the software begins to be used that these scenarios manifest themselves and the gaps are revealed. The cost of retrospectively fixing these gaps in terms of system stability, cost and time can be severe.

The designer and developer were absolutely brilliant; they worked up a prototype as we went along at various meetings where they captured our needs. It was a great way of doing it, especially as we are not very technical…The DCSL architects drew on the screen as we spoke to make sure we captured everything, as well as coming up with ideas of what we could do and how we could do it. The early prototype meant we could see what the finished system would look like and how it would work. It accelerated the whole process and we soon had a full specification ready for approval. Read more.'

Elaine Taylor, Customer Relationship Manager, Alere Healthcare Connections

To solve these problems and to avoid functionality gaps, additional cost and disappointment, for each development project we work on we create:

  • A functioning model – prototype – of the new application. Even the most creative among us can struggle to visualise what software will look like and how it will function from a piece of paper. With the prototype, you won’t have to. Everything is covered and nothing left to assumption.
  • A Product Backlog – a discrete list of functions, fully documented with screen shots and testing criteria, which is the “master list” of all the features to be developed throughout the project.
  • Optionally, and depending on whether we engage under the Agile or Fixed Price model, an articulate and concise functional specification. This is a blueprint for your application; it sets out in writing exactly what you’ll be getting once the development is complete.
  • A sprint schedule –  a plan of what features will be developed in what sprint.
  • A fully project-managed service, with a delivery team comprising a Project Manager, a Scrum Master and a Solution Architect, to ensure the successful delivery of your project on time and budget.

Your prototype

The first step we take is to prototype your new software. This starts with a visit from our Technical Architects to work through requirements in minute detail, during which we make it our responsibility to:

  • extract all the necessary information we need from you to avoid gaps in functionality
  • contribute our own thoughts and concepts based on experience to maximise your return on investment

Then, using cutting edge visual tools we’ll create a functioning model (prototype) of your new system so you can see it working. This includes workflow diagrams to accurately map out the user journey, background processes, and interactive user interfaces to demonstrate how each screen will look and function.

Because of its visual nature, the prototype helps avoid assumption and ensure all parties are in agreement about what is being developed.

Your product backlog

The “product backlog” is a “Scrum” term, specific to the Agile software development methodology, and is the “master plan” for the software’s design. By creating a product backlog it ensures “no stone is left unturned” and forces the whole development team to think carefully about every part of the software from start to finish, before a line of code is written. So what is a product backlog? The backlog is essentially a list of all the tasks to build in your software in order of priority (the first being the most important), divided into categories at different levels. The lowest level is the task, then the PBI (product backlog item), then the feature (which group the PBIs for a particular feature), and finally the epic (which is a grouping of features). It’s quite common for a feature to be a screen or set of screens, whilst an Epic group contains features for a product, sub product or major product area that would comprise multiple features.

Once the backlog has been fully “elaborated”, which is a case of ensuring each PBI has a detailed specification, screen shots and testing criteria, our development team undertakes a process called “poker planning”. This is where each member of the team estimates the time taken to complete each PBI by essentially voting for how complex it is over a range of possibilities, also known as T-Shirt sizes (Small, Medium, Large, Extra Large and so on). Once all members of the team agree on the estimate, and any commercial matters are dealt with, the final step is to put together a high level sprint plan (what features will be allocated to what sprint – which of course is subject to change) and this will be communicated to the rest of the project stakeholders.