When developing a digital product it is incredibly difficult to estimate everything accurately up front. This is due to the very nature of app and web development in that there are a huge variety of tools, languages and versions to take into account and no blueprints or plans to follow. Products that give you off-the-shelf functionality also often come at the price of looking very similar or only providing half of the features you want for these same reasons.

Agile and Waterfall project management can be used to deliver any project, neither approach is better than the other, they just suit different types of projects and the different requirements of the client.

Agile Project Delivery

Agile project delivery has become a victim of its own name. The term agile has been overused and misinterpreted that much recently that it’s common for businesses to latch onto the word “Agile” and assume it must be better than any other alternative.

The main strength of Agile is the ability to start quickly and ensure that a product will always be ready by a specified due date and at a specified cost. In a truly agile project, it is impossible to deliver late or go over budget.

On paper, this sounds perfect, why would you ever choose any alternative when Agile gives you that level of guarantee? As you may have guessed, this assurance comes at a different price, and that is the flexibility on what will actually be delivered at the end of the budget and timeline.

The driving factors in any project are the Time is takes to deliver, the cost/budget and the quality of the final product. Agile locks in place the cost and time but in order to account for the unpredictability of project development, it is agreed before the project starts, that the Quality of what will be delivered cannot be guaranteed.

In order to manage this effectively, an Agile project must be completely transparent and the client must take an active role during the project lifecycle. The development team must be completely transparent regarding what they are working on, how long it is taking them and what they expect to achieve, and in return the client must be honest about budgets and with the help of the project manager, be able to actively prioritise what they want the team to focus on, knowing they may ultimately not get everything they wanted when the time of budget runs out.

To make this process a success, the product manager will capture a high level overview of what the ideal finished product would do in the form of large tickets called Epics. These epics provide a list of functionality that can then be prioritised by the client and development can begin.

As an agile project MUST deliver a functional product by the deadline, development is split into what are effectively mini projects called Sprints.

Each sprint can be between 2-3 weeks and the end result of each, with the exception of sprint 1 which must often include a lot of set up, will deliver something that could be released to the public.

As these micro projects must be releasable, what is delivered must also be fully functional, so bugs must be fixed as they go along and cannot be left until the end like in a waterfall project. This process ensures the quality but does slow down development.

At the end of each sprint is a product playback meeting where the Development team will present their work and then work with the client to amend the priorities for the next sprint. Each following sprint will then work to build upon the output of the previous one, taking into account the new priorities. It is also possible to add in additional features mid project with Agile. You just need to be aware that if something goes in at the top of the list, something must drop off the bottom.

This process continues until there is either nothing left to develop, or the deadline or budget is reached.

  • Fixed Budget – Sprints have a fixed price meaning if you have a budget of £10,000 and a sprint costs £2000 you will know from day one that you will be able to afford 5 sprints.
  • No surprises – As you, the client, are involved at every stage of development and are choosing the priorities yourself, you will know as well as the development team what you will be able to have complete by the end of the project.
  • Guaranteed Delivery Date – As each sprint must produce a shippable product, you know that although it may not have every feature, you will have a product ready when you need it.
  • More Affordable – Due to the continual prioritisation process, the items that are less important to you will be pushed to the bottom of the list. You may even decide you don’t want them at all in the end, reducing the overall cost of the project.
  • Quality Not Guaranteed – You must be willing to accept from day one that you are unlikely to get 100% of your desired features. This can often be hard to swallow, especially if your product is complicated and progress is slow.
  • You must be actively involved – Unlike a waterfall project where the planning is done up front and you sign off a specification, in agile you plan as you go. This means you can’t just sit back and wait for it to be delivered, you are actively involved in the development process at the start and end of each sprint.
  • The risk is placed on the client – In agile, you are effectively purchasing units of development time, not a finished product. When the final sprint ends, the studio is under no obligation to work for free to make sure the product is 100% complete.

Waterfall Project Delivery

Waterfall project delivery is a tried and tested process, and In the same way that Agile has become associated with being lean and current, Waterfall has become associated with how things used to be done in the bad old days when costs would spiral and deliveries were late.

Again, this is an unfair label as an effectively ran Waterfall project will produce higher quality results than an Agile project because delivering an MVP is not an option. For example, you would build a physical bridge using a waterfall project management approach as unless the bridge is 100% complete, it isn’t a functional product. You can’t MVP a bridge.

The main strength of Waterfall is that the risk is transferred to the development team instead of the client. They are responsible for researching and creating the specification and project plan and providing an estimate for delivery of the final product. As the client, once you have communicated your requirements, all you need to do is sign off the specification and agree to the price. It is then on the studio to deliver everything you have asked for.>

It is then the job of the studio to deliver the entire project as efficiently as possible, knowing that any overage incurred is at their cost as opposed to the clients. This usually means the Waterfall projects will cost more up front but the guarantee is that you will get EVERYTHING that was in the specification as opposed to Agile where if you get to the end of your budget and it isn’t finished, you have to buy another sprint.

As the promise of waterfall is that the Quality is guaranteed that means the areas of flexibility in the project are Time and sometimes Cost. The development team will spend a great deal of time creating the specification upfront in order to mitigate as much of these risks as possible in order to make the project profitable but as is often the case, things don’t always go to plan, certain features are more difficult to build and the project will take longer to deliver than initially expected.

During a waterfall project, sprint playbacks or milestone updates will still take place so as the stakeholder, you will be kept up to date with progress, you just can’t make any changes and additions without raising a change request as the specification is the reference point and cannot be amended.

Change requests are permitted but the impact they will have on the already priced project must be taken into account and the budget and timeframe increased to allow for these new additions.
As the project reaches its final stages, it will move from development into a bug fixing phase where the technical debt amassed during the project is collated and all remaining bugs resolved. Before being handed over to you for the final User Acceptance Testing process (UAT) and then final delivery.

  • Fixed Price – As the risk is transferred to the development team, you know that even if the project runs over, that you will not have to pay any more than the agreed price to receive 100% of your project
  • Hands off – The planning and specification creation is all done up front and does not require your active involvement during the project lifecycle. At most you may wish to have regular progress meetings but you may just as equally be happy with a periodic update.
  • Quality Guaranteed – There’s no such thing as a minimum viable product in Waterfall. You will get all of the features you requested when the final product is delivered.
  • Upfront Planning Required – In order to produce the estimate, the specification must be created which requires a period of research and writing. This can take between a few days to a few weeks depending on the scale and complexity of the project.
  • More Expensive – As the risk is transferred to the development team, a degree of padding is often added to the final estimate to help mitigate any uncertainties. This means a waterfall project will cost more up front than it would in agile.
  • Less Flexible – The specification is priced and signed off before development starts and serves as the project blueprint. Any changes or additions requested will be priced and estimated as additional costs of development. You can’t swap items in and out.

Summary and Conclusion

If you’re struggling to decide which approach is best for you, these below examples will help serve as a quick reference and will hopefully resonate with your current situation. 


  • “I need something ready before the trade show but it doesn’t have to be perfect.”
  • “I have a great idea which I just want to get started.”
  • “I’m not 100% sure what the finished product will look like but I know enough to get started.”
  • “I have an approved budget and a team I trust to do their best possible work for me”
  • “I want to produce a prototype, not necessarily a finished product.”
  • “The last thing I want to do is spend days writing, or paying someone to write a specification.”


  • “I know exactly what the finished product should look like”
  • “I don’t have time to be actively involved in the day to day management of the project”
  • “I don’t trust the development team to always be working on my project.”
  • “Project budgets are a secret, I want the studio to provide a cost for the build which I will either approve or reject.”
  • “I can’t accept anything less than 100% of features for this product.”
  • “The board needs the assurance of a well documented signed off specification before they will release funds for the project”

Just be aware that every digital agency will do things slightly differently based on their own experiences, the definitions described in this document are as close to off-the-shelf approaches as possible but that also doesn’t mean you can’t request exceptions if your project requires a little more flexibility or customisation.