Most of our projects follow a typical process from requirements through to user acceptance testing (UAT), with our true agile deliveries being an iterative process of requirements analysis through to delivery via bi-weekly sprints. For this article, assume we are developing a bespoke, web-based, administration system, we’ll also cover the tools we use to make this happen.
The overall process can be grouped into 4 stages. From Requirements and Design to Detailed Design and Sign-off, Development then finally UAT. The Diagram below shows where each of these stages fits in the process.
Requirements and Wire-frames
Naturally the first thing we need are the customer’s requirements, these are gathered over a series of meetings with the customer and documented using mind maps and notes. Each discrete unit of functionality then becomes a story, with related stories becoming an epic.
The requirements are detailed and replayed internally in order to define an estimate. kwiboo uses relative estimation to assign a score to a story, is it bigger or smaller than a known piece of work. Requirements are also played back to the customer for baseline sign-off. Base-lining these requirements is really important for the smooth running of the project and to establish a scope for the delivery.
For this example project a site diagram would be produced showing a hierarchy of screens to be delivered, each screen is given a unique reference (i.e. is a story and this is important later).
The solution architect for the project then creates wire-frames of each of the screens being delivered. Although these wire-frames don’t represent the final look and feel, they do capture an exact list of data presented and gathered on each screen.
Functional Design and Sign-off
A Functional Design Document (FDD) is created, containing a section for each part of the application. These sections are based on the hierarchical site diagram produced in the last section. The screen’s reference is used to tie the system together.
The wire-frames are worked into the Functional Design Document and high level of detail is added for each screen; validation, permissions and notes for the developers.
The Functional Design Document goes through internal review then is passed to the customer for sign-off and feedback.
The project manager, development architect and creative director meet to discuss the project and agree the tasks for the teams. Using the Model View Controller paradigm on Microsoft’s ASP.NET MVC platform, the architect creates the views and controllers for the HTML team to work with and the Creative Director designs each of the screens in Adobe Illustrator based on the functionality described in the FDD.
By this point, the customer has signed off the Functional Design Document, containing the wire-frames and descriptions for each part of the application. An internal project kick-off meeting sets the scene. The project manager arranges regular daily meetings and creates the sprints ready for the design and development teams to work to.
The kwiboo project board displays project status, time spent vs. time estimated, time since last source control check-in etc. We’ll cover this in more detail in a future post.
An initial 2 week sprint is created for both teams (HTML and Development). HTML team build and hand over each view to the developers once visually complete so functional development can proceed. Every view is numbered and has a corresponding task in the sprint and time management software. The daily meeting is used to monitor the progress and raise any observations, concerns or delivery blockages.
As tasks are completed, the overseeing Designer or Architect inspects their team member’s work and provides feedback where appropriate.
Once all tasks are complete on the sprint and signed off internally, the next sprint begins. This process continues until the project is delivered. Using Continuous Integration tools such as Jenkins or Microsoft’s Team Foundation Server, a new release will typically be made at the completion of a sprint for review by the customer.
Weekly reports are delivered to the customer, and the customer will provide feedback on the latest release.
Before any project can go live, the customer needs to test and accept the final product. Usually the customer will work on their own list of acceptance critera, based on the base-lined requirements gathered earlier. kwiboo will also use these requirements to define unit tests and test the delivery. The regular customer interaction and weekly reports help prevent any surprises in delivery vs requirements. Customer involvement is key to agile.
All projects are different, but a successful outcome is always achievable if a project is set out with a realistic plan, requirements and budget. kwiboo has been delivering innovation projects for 8 years. In this time technology and tools have moved on a great deal and we’re fortunate to have experienced the things that work well, as well as the tools and methods that have not survived.
If you are interested in hearing more about our IT delivery practice please contact Alex Driver