Project Delivery

Dunstan Thomas has a robust and repeatable approach to projects. Our development methodology is Agile SCRUM with the delivery aspects split into phases closely following the RUP (Rational Unified Process) stages of a project. This combines the agility of the SCRUM methodology with the necessity to phase the project to provide commercial control and visibility. Dunstan Thomas uses UML (Unified Modelling Language) to document the design of a software system. UML is a standard industry notation for modelling software and Dunstan Thomas are a leading advocate of UML with industry experts and a UML Training and Consulting practice.

The Phases

Phase Description
Discovery (Planning & Initiation P&I) Define project vision goals, scope and high level architecture.
Elaboration Prototype elements of the design to identify risk in the project.
Construction Software development phase of the project.
Transition Delivery and hand over of the solutions to the client.

These phases break down into sub phases (sprints) reflecting the Agile SCRUM development methodology. The diagram illustrates the phases as they occur over time and the work activities that occur during these phases.


Discovery (P&I)

The purpose of this phase is to understand, document and agree the project vision, goals, business domain, high-level architecture, deployment configuration and initial project scope. The Discovery phase is run as a series of workshops. Outputs of the Discovery phase include:

  1. A clearly stated project Vision / Goals document.
  2. Identification of the key systems, subsystems and components to be developed captured as Use Cases
  3. The deployment / non-functional considerations to be considered during development
  4. For each of the key systems, subsystems and components identified, an understanding of:
    • Behaviour,
    • Responsibilities,
    • Functionality,
    • Data,
    • Interfaces,
    • Dependencies,
    • How it will be tested.
  5. UML Diagrams
  6. Wireframe diagrams and UI/UX mockups
  7. Production of the project backlog and story point estimation
  8. Prioritisation of the work packages based on business value.
  9. Effort Estimates Plans and Timelines



The purpose of the Elaboration Phase is to build and deliver a prototype that forms part of the overall solution. This is done so that technical and other project risks are eliminated or reduced.  There are two approaches to selecting which component or subsystem should be developed in this phase:

  1. that has technical risk attached to it in order to drive out project risk as early in the process as possible,
  2. or to identify a work package that will provide business value early, and hence give an early return on investment.

Elaboration is conducted in Sprints of either 2 or 3 weeks duration.


The purpose of the Construction phase is to build all requirements within the scope of the project. Development is broken up into sprints of 2-3 weeks with continuous build and testing of the software throughout the process.

It is usual for the development team to be expanded during Construction reflecting the ability for work streams to be developed in parallel.

During the Construction Phase, regular reviews and retrospectives are held with the Client to ensure that early visibility is given, and so that both parties prioritise remaining work based on the business needs and requirements.

This incremental and iterative approach to building software enables and encourages more functionality to be delivered throughout the project.


The Transition Phase represents the point in the project plan where it is being completed, and any remaining hand-over or deployment requirements are considered. Not all projects include a formal Transition Phase, but it can include some or all of the following tasks:

  • Handover into Support and Maintenance
  • Training of super users and end users of the system.
  • Live system data configuration
  • Data migration
  • Final deployment & Go-Live activities
  • Project Closure meeting
  • Warranty

For more information on our project phases Contact Dunstan Thomas.

Agile Development – SCRUM

Scrum is an iterative and incremental Agile framework for managing software development. It is a flexible software development strategy where a development team works as a unit to reach a common goal, in contrast to the traditional Waterfall approach to development. It enables teams to self-organize by encouraging close collaboration of all team members and daily face-to-face/online communication among all team members.

A key principle of Scrum is its recognition that during a project the customers can change their minds about what they want and need (often called “requirements churn”), and that unpredicted challenges cannot be easily addressed in a traditional predictive or planned manner.

There are 3 core roles which represent the scrum team as described below:

Product Owner

The Product Owner represents the stakeholders and is the voice of the Client. The Product Owner writes user stories, ranks and prioritizes them, and adds them to the product backlog. Scrum teams should have one Product Owner, and while they may also be a member of the development team, this role should not be combined with that of the Scrum Master.

Scrum Master

A Scrum is facilitated by a Scrum Master, accountable for removing impediments to the ability of the team to deliver the goals and deliverables. The Scrum Master is not a Team Leader or Project Manager, but acts as a buffer between the team and any distracting influences. The Scrum Master enforces the rules of Scrum, chairs key meetings, and challenges the team to improve.

Development Team

The Development Team is responsible for delivering potentially shippable increments (PSIs) of product at the end of each Sprint. A Team is made up of resources who do the actual work (analyse, design, develop, test, document). The Development Team in Scrum is self-organizing with an interface to the Project Manager responsible for the delivery of the entire project to the Client.

The Sprint



A sprint (or iteration) is the basic unit of development in Scrum. It is timeboxed  i.e. restricted to a specific duration. This duration is fixed in advance for each sprint and is normally a 2 or 3 week period.

Each sprint is started by a planning meeting, where the tasks for the sprint are identified and an estimated commitment for the sprint goal is made, and ended by a sprint review-and-retrospective meeting where the progress is reviewed and lessons for the next sprint are captured to facilitate continuous improvement.

A task board is used to see and change the state of the tasks of the current sprint, like to do, in progress and done.

Sprint Planning Meeting

At the beginning of each sprint a Sprint planning meeting is held to:

  • Select what work is to be done from the Product Backlog
  • Prepare the Sprint Backlog that details the time it will take to do that work, with the entire team
  • Identify and communicate how much of the work is likely to be done during the current sprint

The Daily Scrum Meeting

A 15 minute daily team communication meeting or standup is held where each team member answers and communicates three questions:

  • What did I do yesterday that helped the Development Team meet the Sprint Goal?
  • What will I do today to help the Development Team meet the Sprint Goal?
  • Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

Any impediment/stumbling block identified in this meeting is noted by the Scrum Master and resolved outside of this meeting. The Scrum is not the forum for detailed technical discussions.

Review and Retrospective

At the end of a sprint, two meetings are held as follows:

Sprint Review Meeting

  • Review the work that was completed and the planned work that was not completed
  • Present the completed work to the stakeholders

Sprint Retrospective

  • Team members review the past sprint
  • The Team makes continuous process improvements
  • Two main questions are asked in the sprint retrospective: “What went well during the sprint” and “what could be improved in the next sprint?”

These meetings are facilitated by the Scrum Master.


The product backlog is an ordered list of requirements maintained for a product. It consists of features, bug fixes and non-functional requirements. Backlog items are ordered by the Product Owner based on considerations like risk, business value, dependencies, date needed, etc.

The Sprint Backlog is the list of work the Development Team must address during the next sprint.

Burndown ChartsSimple_Burndown_Chart

The Burndown Chart shows remaining work in the sprint backlog. Updated daily, it provides visualisation of sprint progress. The release Burndown Chart shows the amount of work left to complete a version of the software or major release and covers multiple sprints.


For more information on our development methodology Contact Dunstan Thomas or to learn more about some of the industry verticals we work within visit our Markets pages.