Monthly Archives: November 2018

The Agile Model Advantages and Disadvantages

If you are researching Agile, or interested in giving it a go for your next project you need to know all of the pros and cons. If this sounds like you, you are in the right place.

What are the Agile model's advantages and disadvantages? The advantage of agile is speed, flexibility and transparency to the end user. The disadvantages are its difficulty to project manage and scale for large projects.

Understanding the pros and cons is just one part of the challenge, you need to know how I have come to these conclusions to fully appreciate this. Continue reading to get the full in-depth low-down.

Quick Navigation

Agile is a really good, fast and efficient methodology to roll out a software project. If you are testing, which primarily you will be if you're on this page, or a developer, it's a quick way to get stuff out as soon as possible.

Disadvantages, if you're more of a traditionalist or you've been in the game for as long as I have, you may find a lack of documentation can be a real headache and hard to get your head around. So stick with me. In this article, we're going to go more in depth into explaining these advantages and disadvantages and also give you some other in depth information about Agile.


Speed of Delivery

In a nutshell, Agile is an incremental software development methodology that allows you to get quick feedback on your code modules and get stuff out quick to market.

The way it's typically implemented is, you break down your delivery into small modular sprints and you test and develop, get feedback and reiterate around, around again, allowing you to get code completed quicker.

An added benefit is, rather than having to spend months on planning, designing and building documentation before you start coding, you can dive right in.

So one of the advantages, as you may have guessed  is the speed of delivery.

Early Feedback

Agile is great for getting the ground running, getting something out and getting early feedback.

Without Agile, you could you spend months of planning and designing, only to find out that your efforts are no longer needed by your stakeholder or they just generally do not like what you've delivered.  

And believe me, I've been testing for a long time now and I've seen this happen before. Early feedback falls in line with speed of delivery, you can roll out a few iterations.

Let's give you an example. You could be building a graphical user interface for a web application, rather than spending months on design and documentation then having a UAT testing phase at the end to introduce your customer to the actual product.

You could instead use agile, roll out a very basic wire frame of the graphical user interface with a one or two weeks sprint, roll it out for some testing, get some feedback from the customers.

And then with the feedback that you get from them, whether it's positive or negative, you can actually update your designs or code to be in line with what their expectation is and reiterate that again in the next sprint.

Flexibility with Late changes in requirements

This is another great thing. Agile is not as rigid as the V model or the Waterfall model. So you do not have to go back to design and documentation if there is a change in requirements and avoid loads of meetings to agree the changes.

You can simply "tweak the changes", add it to the next sprint, redevelop the code, update the code, or whatever it may be, retest, and then roll it out.

Close collaboration with project team

One of the benefits of this is you can collaborate closely with the project team and it allows "buy in" from all parties in a project team.

For example, the project manager can have a good view of the next sprint. The stakeholder can get some feedback on the project early, for example, at the end of a two week sprint, before it's actually too late to make changes.

It's also a good opportunity for testers to get an early hand on the code. In summary developers, stakeholders and all project members tend to collaborate tightly together.

One of the great things in Agile, which is known as a scrum, is a great opportunity for all stakeholders to get together on a daily basis to see how the project is unfolding.


Hard to estimate the length of the project

Now one of the disadvantages is it's hard to estimate the length of the project. Admittedly, this depends on how you implement Agile, because every company has their own flavor of how they actually implement this.

Regardless of what you may have read in a book, every company does it slightly different and being in the game for just over 18 years at the time of writing this, I've seen many different flavors or implementations of Agile.

So in summary, sometimes it's very hard to estimate the length of the project because there is a tendency to continually add new sprints and modules and never really have a known end date. 

Lack of documentation. 

If you're a traditionalist or someone that's worked in the game for quite a long time and you've used models such as the V model, you can find the lack of documentation in Agile quite hard to actually deal with.

It's something that is seen as a negative, but it's a matter of opinion actually because some people believe this is a bonus because they don't have to get bogged down with months of planning and filling out documents.

Their argument may be, they'd rather use that time on getting feedback from their clients. So an advantage for some, but in my opinion a disadvantage is the lack of documentation.

Scope creep. 

If you have been testing for a little while, you've probably heard of scope creep before. Scope creep in general is when you have some agreed requirements, but then you find over time you start to go outside of those requirements and you start to deliver something slightly different.

Sometimes this can actually be a gift, but it can also be a curse because you can end up spending more money on the project than was expected and delivering something which is slightly different to what you've agreed for.

This can be quite a costly mistake. In Agile it's very easy to do this because it's so flexible, you don't have the entire scope nailed down from the beginning. So it's very easy to go off on a massive tangent.

Related Questions:

When should you use the Agile model? That's a very good question. In my opinion, the Agile model is really good for projects where you want fast delivery, something which needs feedback really quickly.

It's ideal if you've got a web application that you can get feedback from your client, update and go forward. If it's a more complex financial application, it may be debatable if this is the best model for you.

I'm not saying it's not being used in applications like this before, 'cause I'm sure it has, but the big thing is if you're using Agile and you've got a very large team, which has got mixed opinions on agile is quite hard to get the buy in from every member.

For it to work really well, you need the "buy in" from all parties. You need to have all stakeholders in agreement and it's good to use when you start from a fresh, maybe as a startup where everyone's all on the same page, as an existing legacy system.

For example, a financial application that may have been around for 10, 20 plus years using the V model for example for many years and then overnight to switch to Agile and using existing processes, it can be very hard to actually implement.

So what are the advantages of the Agile methodology over the Waterfall model? The Waterfall model is one of the more traditional models where it's heavily reliant on documentation and following a very sequential road to delivery.

The Agile is quite efficient and quite agile and hence the reason why it's called Agile, because it allows you to basically make quick changes and it's very good at rolling out fast delivery and getting fast feedback.

What is an Agile Testing Acceptance Criteria?

In my years of testing one of the most important things I have identified is Acceptance criteria. Unfortunately, I have seen too many projects focus on what they think is right, rather than what was agreed and defined in the Acceptance criteria.

What is Acceptance Criteria? Acceptance criteria is the agreed conditions that a software program should meet to be accepted by a customer or stakeholder. It defines what is acceptable by the program to insure quality.

Typically, this acceptance criteria is broken down into 3 areas, functional, non-functional and performance. If you have been around in testing for a while, or been looking for testing jobs, its likely you have heard of these terms before.

Functional Criteria

As the name suggests this breaks down the functional areas, such as “A User Login”. This is a specific function of the system that will have acceptance criteria, such as, once a valid password and user name is provided, the user will gain access.

Non-Functional Criteria

A good example of non-functional is the design and layout of a corporate website. This is different to a functional module I this sense. So, if we extend the example of the corporate website, you may want your site to follow your agreed brand colours. Therefore, a non-functional criteria item could be verifying this has been met.

Performance Criteria

Performance is different to functional. It focusses on certain agreed performance metrics for the software. For example,

“The system must load the contacts page within 10 milliseconds”.


“The system must be able to support the load of 100 simultaneous users”.

These are just quick examples to make sure you understand what I a mean, they are not the perfect example of a well drafted user story.

What is the difference between an Acceptance test & Acceptance Criteria?

Acceptance criteria, done correctly, should not explicitly state how to technically do the solution. It should clearly state the intention. For example, it shouldn’t say to authorise the invoice, the supervisor must click the “A” key. It should be saying; a supervisor can authorise an invoice.

In other words, it should not be biased to any form of implementation. The design and execution of the test is different, this is more for an acceptance test.

Acceptance Tests, on the other hand are tests to prove that the acceptance test criteria has been met. In agile, they are typically derived from User stories. These tests are usually conducted by the actual user. Which is different to unit tests, for example. Because Unit tests are usually ran by developers.

These tests are also referred to as “black box tests”. Reason being, the user looks at the tests at a high-level functional level, without any need to understand the coding conditions and interaction between modules.

White box tests, such as unit testing on the other hand, focus on how each code module interacts together and focuses on the inputs and outputs of the modules.

How is Acceptance Criteria used for Agile User Stories?

Acceptance Criteria is closely tied to a User Story. The user story will prove if the Acceptance criteria has been met. This is why it is important that the criteria is clear with an obvious pass or fail. In other words, it should not be subjective or ambiguous.

Think of the Acceptance criteria as the foundation of your house. If they are not sturdy, the whole development project is doomed!

In Agile The user stories are created to prove that the criteria has been met. Following on from this, Acceptance tests are created to prove that the user stories have been implemented. This can be manual or automated tests, that choice is down to the team or business.

Test Estimation and Acceptance Criteria

Once the criteria is defined it is possible to group the user stories in to modular tasks. Once this is done then this will help to plan and estimate testing activities.

Who Actually Creates the Acceptance Criteria?

This task is usually done by the customer or stakeholder. However, the process involves close collaboration of the project team to review, agree and refine the requirements.

This review and collaboration is important because, whilst the customer knows what they like, they may find it hard to define this within a framework that can be used to code or test. For example,

Saying things like: “The system should load fast”

This statement is not a useful or useable Acceptance criteria. Because it doesn’t define what “fast” is. Believe it or not, fast can mean something completely different for each individual in a project team. If we use the house analogy again, if you asked your builder to create a “Big House”, you could be thinking a 6 bedroom detached, he could thing a 3 bed semi, with large double rooms, are you with me?

So, this is why they are reviewed and defined.

Related Questions:

What is an acceptance criteria format? One of the most common formats for acceptance criteria is the “Given when then” format. It makes it easier to define it. Like most things it’s easier to explain with an example:

Given [a certain pre-condition], When I do some type of Action, Then I expect this to happen

This is quite an easy format to follow for any given scenario you may have.          

How can Acceptance Criteria Benefit the Project? It is very easy for a project to go over time and over budget. But with the use of a well-defined criteria it can help the development stay on track and focus on what needs to be delivered.

What is an example of an Acceptance story? If we use a banking application as an example. You may have the following acceptance criteria:

“The users bank statement cannot be displayed if an unknown bank user ID is provided”

This criterion may be accompanied by this User Story:

As a Bank User
I Can See My Bank Statement
So that I know how much funds I have

Dos and Don’ts for creating Acceptance Criteria? : To make life easier here are some do’s and don’ts to create your criterion:

  • Do: Always create it before development. Don’t get fooled into thinking you can start development and then mould the criteria around what you have created. The idea is to the let the criteria guide you, not the other way around.
  • Do: Always make sure that each item can be tested independently. In other words they must have a pass or fail scenario.
  • Don’t make any item focus on the end solution. The acceptance criteria should be focussed on the “What”, not the “How”. Meaning you should be focussed on the end result that could be solved in many different ways using any software solution.
  • Do include functional as well as non-functional criteria. As explained earlier, both of these are equally as important.


Hopefully this has helped you to understand What acceptance criteria is and more importantly how you can use it for your agile project in the near future.


Skip to toolbar