Category Archives for "Agile Testing"

Does UAT exist in Agile? (Other Acceptance Tests?)

If you are interested in UAT or acceptance testing in general. You may wonder if it is used in Agile or other testing models.

Does UAT exist in Agile? Yes, UAT does exist in Agile. However, it is not reserved for the end of the project. Instead, it can be performed at the end of each sprint. There are other forms of acceptance tests performed as well (more on this later).

Now that you know that UAT is included in Agile, I will go on to explain what other types of acceptance can be involved, who typically does the testing, the benefits and much more…

What is acceptance testing?

Acceptance testing is similar to system testing from the perspective that you’ll be testing the entire system. However, in acceptance testing, it can form a decision if the system is viable for deployment.

It is also used as a quality gate for regulatory or contract related projects (more on this later).

What are the objectives of acceptance testing?

There are a number of different objectives for acceptance testing.

However, the overarching objectives are to get confidence that the system has been built to the user’s expectation.

  • Verify the functional and non-functional aspects of the system are fit for purpose.
  • Verifying that the system works as specified (based on requirements).

Are defects expected to be found at this stage?

Acceptance testing is typically assumed to be at the end of the SDLC process. Therefore, the assumption by all parties is that the system has been thoroughly tested. And, it is expected that there should be minimal or no new defects found.

In reality, finding no defects is quite unrealistic. Because you will inevitably find some defects. But, what I would say is, if there is a large number of defects found at this stage it is definitely a red flag.

In most cases, if there are too many defects, it is regarded as a high project risk. And often recommended not to deploy the code.

In my experience of testing, had we have found a large number of defects during the acceptance testing stage, there would have been a lot of questions asked. We would also expect to be questioned why simple defects were not picked up during testing. Believe me, these are uncomfortable questions to answer, especially under pressure.

Different types of Acceptance Testing

Now that you understand what the objectives of acceptance testing is. It is important to understand that there are various other types of acceptance testing. Each different type has different objectives and resources to perform it. They are as follows:

  • User Acceptance Testing (UAT)
  • Operational Acceptance Testing (OAT)
  • Contractual
  • Regulatory
  • Alpha & Beta

User Acceptance Testing

user acceptance testing uat

User Acceptance Testing (UAT)

When acceptance testing is mentioned most people will typically assume UAT. However, it is not the only form of acceptance testing. I will agree though, it is one of the most popular, from my experience.

UAT is an opportunity for the end-user to verify and get confidence that the system performs as expected.

This usually revolves around the user requirements (Test Basis – more on this later) that were drafted from the initial stages of the project.

Who performs UAT?

This stage of testing is typically performed by business users, typically end-users who will be using the system on a day-to-day basis when it goes live. These resources are usually had picked based on their knowledge of the current system (if its an existing system, that is being upgraded).

However, if it is a brand new Greenfield system, that has never been used before, then you will typically have the users who are expected to use the system in anger once it goes live into production.

Operational Acceptance Testing (OAT)

Operational acceptance testing is another form of acceptance testing that is often overlooked. Essentially this involves highly technical resources, such as tech support.

Objective of OAT

The focus of this acceptance testing is different from UAT because these testers want to feel confident that they can support the system when it goes live.

For example, this could include tests like backing up and restoring the system in a simulated disaster (disaster recovery), etc.

This is quite a technical level of acceptance testing and requires experts that have had, ideally, years of experience or acquired a high level of skills and knowledge in a short space of time.

Contractual and regulatory acceptance testing.

Quite a mouthful but ultimately it comes down to two separate types of testing. but there are aspects of which overlap.

Contractual Acceptance

Contractual acceptance testing involves testers (or representative testers) verifying that the system in question meets the agreed contract specification.

The agreed contract specification is often used to verify that the system is operating as expected. This contract and agreed behavior is usually created at the start, once a contract is agreed, at the very beginning of the project, way before testing starts.

Regulatory Acceptance Testing

Regulatory acceptance testing is slightly different because it involves testing to verify that a system meets certain regulatory standards.

My example of regulatory testing

During my experience of testing, I worked for an energy company (Gas & Electric). They were launching a Customer Management System (CMS) in a new European country.

However, the difference with this particular country is, they had a strict regulatory licensing quality standard that needed to be proven and verified before the system could go live and be awarded its license.

Therefore, I was drafted as a test manager to prove to the regulatory representatives that the system was fit for purpose to go into production in their country.

Typically for these regulatory acceptance testing, you will have a neutral third-party company that will verify what you have tested to ensure it meets their standards.

Witness & Test Asset Testing

I also had experience of this, which included verifying that the test assets were created as per their specification as well as face-to-face visits to witness test what were testing.

Depending on who you are working with these tests can be quite stressful. Why? Because they usually have to be done within a restricted time frame. And, there is not usually much chances to get this right.

And, to make matters worse, the stakes are usually quite high because of the investment that has been made to get the software to pass the regulatory standards before the system can go live.

Alpha or beta testing

Alpha or Beta testing is a strategy used to verify that the system is fit for purpose. However, it is typically used by developers of commercial off-the-shelf software (COTS).

The objectives of this testing is to get an early understanding of the system and verify it is fit for purpose.

Big players that use Beta Testing

You may have even noticed some of these strategies used by big players such as Google. Sometimes they roll out an early stage “Beta” and get user feedback, before rolling out the final product.

The idea is to get a good dataset from the intended customers to understand if the system is working before you roll out the fully tested and production-ready version.

What documents are typically used as a test basis for Acceptance Testing?

Like most phases of testing, test cases will typically be drawn up. However, a test basis is required to write the test cases against, are you with me? Typical documents that are used for test basis are as follows:

  • User requirements.
  • Business requirements.
  • System specifications
  • Use cases
  • etc.

However, we also discussed OAT earlier. This usually requires some of the following:

  • User manuals.
  • System backup & restore procedures
  • Operational guides
  • Deployment instructions
  • etc

Acceptance Test objects.

As well as the test basis documents. There is obviously the actual objects that will be tested. Such as:

  • The full test application (System under test)
  • Configuration data (especially with (COTS)
  • Business processes
  • Reports
  • Operational processes
  • etc

What defects can you expect to see?

At this stage, defects are expected to be very little. However, as I mentioned earlier, you will expect to see some. The types of defects that usually show up during this phase are as follows:

  • The system not meeting the requirements
  • Non-functional issues, such as security-related
  • Non-functional issues related to system performance.
  • Functionality not meeting a regulatory or contractual agreement.

All of these examples are important and need to be investigated. And, at this stage in the project, there is very little time to rectify these issues.

Who is usually responsible for these tests?

During this testing, depending on which type of acceptance testing, there can be various different resources testing it.


For UAT, you would expect the end-users to be involved or potentially some of the stakeholders.


For OAT, this is typically done by system administrators, support workers or a knowledgeable resource that has lots of working knowledge of the system in question.

Regulatory or Contractual

Regulatory and contractual acceptance testing is typically done as a collaborative effort with the actual system testers and a representative (from the regulatory body or third party contract owner/partner).

When is acceptance testing typically done?

As mentioned earlier most people assume that acceptance testing is done at the end of testing after system testing has completed.

In my experience, this is usually been the case. However, it does not necessarily have to happen at this stage. Especially when you are dealing with iterative development methodologies such as agile.

This is because each iteration is like a mini-project within itself or known as a sprint (click here for a full explanation). You may find different types of acceptance testing done at the end of each sprint, treating it like a mini-project.

Who is the scrum master in agile?

Agile without the Scrum master is like an orchestra without a conductor. In my years of Agile, this person is always the central person in the team.

Who is the scrum master in agile? The scrum master is the organisor of an Agile development. Think of this person as the process manager of Agile or if you like, the linchpin that brings all the related project team together to follow the Agile process.

Now that you understand from a high level what a scrum master does, you need to understand exactly what they do and how they fit into the process. If this interests you, please read on for more information.

What does a Scrum Master do in an Agile Scrum?

During an Agile scrum all project team members huddle together for a quick “stand-up” meeting. The reason it’s a stand-up meeting is so it physiologically reduces the expected duration.

Meaning it is likely to be shorter and concise if you do not sit down, well that is the idea.

The Scrum Master is effectively the organiser of the scrum and really wants to establish three key peieces of information from each scrum meeting attendee:

  • What did you actually do the day before?
  • What is your plan for today?
  • Are there any blockers in your way?

Even though this may sound like the scrum Master is similar level to a project or programme manager, in reality this is not the case. The scrum master is just responsible for facilitating the scrum, not the outcome of the project or programme o work.

What is the Scrum Masters Objective During a Scrum?

During the scrum, we just established what the scrum masters role is. But what is their objective you may be thinking? Well they have a challenging task of keeping the team focused and most importantly avoiding blockers that could prevent progress within the current, or future sprints.

As well as this, they have to make sure the team is in agreement with the direction of the day. For example, if you are asked “what is your plan today?”. Your response may be: “Work on the second drop down list data feed”.

There is a chance that your response my cause an objection or suggestion to this a bit different. This is where scrum master is valuable to keep everyone on track and reach an agreement.

What Authority Does a Scrum Master Have Within an Agile Project Team?

As discussed earlier, the scrum master is not a project or programme manager. And in fact they may not have any real project level authority at all. However they do own the “process”.

What does this mean? Basically they can decide how the scrum is organised, who speaks next. Or even if they want to make alterations to the sprint duration.

Bare in mind, all of this is in theory. However, in my experience of testing throughout the years, the real authority to make these decisions stick depends on the politics of the company you work for and how respected that individual really is. But on paper, they should have the ability to do this.

What Value Does the Scrum Master Add to the Product Owner?

Apart from the actual scrum itself, the Scrum Master also ads value to the Product owner. In particular making sure that the team fully understand the product backlog and importance of having very clear and understandable backlog items designated to each sprint.

What Value Does the Scrum Master Add to the Dev Team?

The value add here is helping the development team come up with the highest quality products that they can. This is mainly by helping to remove any blockers that may be preventing their progress within the current sprint. Also making making sure they understand the sprint plan and how that related to the product backlog.

Overall what value does the scrum master add to the organisation?

In general the scrum master works to help the organisation understand and adopt the scrum process. Initially it can be hard to get a project team to conform because they are not used to the new process. This is where the scrum master really adds value.

What is a Typical Scrum Master salary?

According to glassdoor, a scrum master in the United states earns, at the time of writing, $115.992 and in the UK, approx £50,000. Obviously these are averages and depending on where you live, the company you work for, this can vary quite significantly.

Do you need a degree to be a Scrum Master?

You don’t need a degree to become one, but you do need to have a good understanding of Agile Scrum. In addition to this, it is advisable that you have a good idea of how your company works, the products they use and the culture of the organisation.

This is because the Scrum Master needs to work with a lot of people of varying levels of skills and hierarchy, and to gain their respect and do well, you will need these skills.

How long does it take to become a scrum master?

To become a qualified Scrum Master you will need a qualification. For example the Certified Scrum Master. However, this is a certificate, it will be the stepping stone in your carrer, much like an ISTQB foundation qualification is a stepping stone in testing.

My point is, you will still need some experience in the company to really be considered for the role. Also, bare in mind in reality there are people out there now fulfilling this role of Scrum Master without this qualification, much the same as there are testers without ISTQB qualifications.

Related Questions:

What is the Certified Scrum Master (CSM) Exam? CSM is a certification provided by the Scrum Alliance. Once you have complete the CSM training you can can take the exam and have the opportunity to be certified. The course training is typically done over two days with a qualified trainer.  These trainers are referred to as “Certified Scrum Trainers”.

How long is the CSM exam? The exam is about an hour and is done using an online system. It is possible to pause, resume during the exam, so the duration is the actual time. The elapsed time could be longer if you pause and take longer to complete it, if that makes sense.

To pass the exam you need to get at least 24 out of the total 35 questions that are asked. The great thing about this exam is that once you submit your answers you can get an instant score. This is because it is a multiple choice question exam, meaning you have fixed answers.

What happens if you fail the CSM Exam? If you fail the exam you get the chance to re-take it again. As long as you do this within 60 days you won’t be charged. However, if you fail it again there will be a fee tat you’ll need to pay to try again.


What is a Sprint In Agile?

If you are interested in Agile, no doubt you have heard of Sprints. But what are they? Well in this article I plan to reveal all and explain more.

What is a Sprint in Agile? Sprint is an iteration of time boxed work that is used within the scrum framework of Agile. Typically, these sprints are short, modularised pieces of development/testing which aims to meet the sprint goal.

To truly understand how Sprints fit into the whole Agile methodology, you need to read on. I will explain the different between sprints and scums, how sprints fit into the Agile Scrum framework and more detail about sprints in Agile.

What is the difference between a scrum and a sprint? 

In some cases people may get these confused, but effectively they're very different. A scrum is a meeting, that is typically done on a daily basis and it's an opportunity for the team members to get together to make sure they're still on track for the sprint.

It is an opportunity to work through any challenges they may have had the day before, and to focus their attention on what needs to be done for that particular day.

It's usually a very short 15 to 30 minutes get together, and then you continue with your rest of your day, and the main focus is on the sprint itself.

The Sprint on the other hand. Is an agreed iteration of work to be delivered in a agreed timeframe.

What an Agile sprint cycle? 

A sprint cycle is really just another way to say a Sprint. As discussed earlier, a sprint is a timed boxed piece of work used in the scrum framework.

What is Agile sprint planning? 

Sprint planning is effectively planning the up coming sprint.  It is a collaborative effort which typically involves a scrum master.

For those of you that are familiar with the framework of scrum. The idea is, the scrum master facilitates the planning of upcoming sprints, and agrees, with the project team, all of the backlog items in the product backlog that are going to be used in each sprint.

What actually goes into a sprint? 

As discussed earlier, a sprint it is an agreed selection of backlog items that will be delivered in an agreed time frame. Obviously the very specific tasks that are delivered are subjective to the project that you're working on. 

For example, let's say that you are building a new banking application, then maybe you'll have two weeks to work on just the graphical user interface and that will be the focus of the first two weeks.

The day-to-day scrums will make sure that you're on track to deliver that sprint goal.

How long does a sprint usually last? 

As you can imagine, there is a bit of subjectivity here because it depends on your individual project, or how your company works, but the average is about two weeks.

It can be shorter, it can be a week or it could even be longer. It's not recommended to have really long sprints because the whole beauty of Agile is to have quick sprints, and then get quick feedback and quick iterations.

To cut a long story short, two weeks is the average, but you could be looking anywhere from one to four weeks, but most people go for two weeks.

Related Questions:

What is a sprint backlog? A sprint backlog is effectively a list of tasks that have been identified to be delivered throughout the entire Agile project.

Each sprint consists of the agreed list of work items, for example, the two week sprint, that are taken from the sprint backlog. Effectively, the sprint backlog  could literally be a document which has all of the pieces of work and development that are gonna be done throughout the entire project.

What is a sprint forecast? A sprint forecast is a scrum guide that refers to what will actually be delivered throughout the project itself.

This is largely reliant on the product backlog and the items that are selected for each sprint. It gives you a forecast of where you're going and where you're going to get to with your actual project.

What is a confluence sprint planning template? If you're into the world of Agile, then maybe you've come across confluence before.

Effectively, confluence is a collaboration tool that is used to help teams to collaborate and share their knowledge. The sprint planning template is just a template within this tool which enables Agile teams to work more effectively together, and effectively that's what it is.

What is the Difference Between Waterfall and Agile

If you are interested how Agile compares to a more traditional methodology such as the Waterfall, you are in the right place. In this article I will break down the key differences between . these very different software development approaches..

What is the difference between Waterfall and Agile? The main differences is an iterative approach as opposed to a rather rigid sequential approach. Agile has agreed work packages, called sprints, that can be changed or improved as the project progresses, as appose to waterfall which has sequential phases from design to development through to testing.

To get the full detail on this continue to read on. I will break down 11 differences between Agile and the waterfall method.

Phases Instead of Sprints

So as mentioned briefly before Waterfall has phases, instead of sprints. In Agile you have bits of functionality that are grouped together in what is formerly known as sprints.

Waterfall Phases instead of Agile Sprints

For example, if you're working on a website graphical user interface, e.g. your first sprint might be the general layout of the actual graphical user interface (GUI).

And then at the end of the sprint, after testing the developed software, you would present this to the team so that they can get an idea of if they like what they see.

After they agree with the functionality, the next sprint maybe to improve on that, add more features or functionality and do this in a continual process until you get to the final end product.

As opposed to the Waterfall model where you have a requirements phase, a design phase, and each phase is locked down, signed off, and then you move to the next phase. Once the requirements are done, there's no going back.

Rigid Phases Vs. Flexibility

So as I previously mentioned, in th Waterfall method, each phase is effectively locked in and agreed, without any flexibilty.

So what this means is, once you, for example, finish the requirements phase in Waterfall, you then have a document which is signed off by all parties and once that's done, that is cast in stone. You will then stick with these requirements to the very end of the project.

Whereas, with Agile, you will effectively be evolving the requirements ongoing from the beginning to the end of the project. So at the beginning the whole requirements could actually change significantly by the end, which gives you more flexibility.

Requirements locked down versus dynamic changes to requirements. 

Waterfall Requirements Locked Down vs Dynamic Changes to Requirements in Agile

So a bit of an overlap with the last one, but the main focus here is once the requirements are done, there is no changes. They're locked down and they're cast in stone.

Effectively it's quite expensive in Waterfall to make a requirements change because you'd have to go back to square one, make changes to the requirements doc, which is pretty much like the underpinning overarching document that dictates the entire project phase and then roll out the design implementation and testing all over again.

Whereas in Agile is quite dynamic and you can effectively make changes on the fly and then work them into the next sprint of work and gently evolve. Both of these, by the way, have their pros and cons, but there is a very big difference between these models.

Testing once versus incremental testing. 

What this basically means is in the Waterfall model, you have a very specific testing phase. Once you exit the testing phase and it's signed off, you are then done with testing for the entire project.

With Agile, on the other hand, you break everything up into sprints and effectively you're testing throughout the whole project and you can continually change requirements. Development code will change and you'll continually keep testing within each sprint. 

For example, for those that don't know what a sprint is, it is a short phase that could be anything as quick as two weeks, finish a piece of functionality, test it and then restart the next sprint and you're continually testing, developing, coming up with requirements and so on and so on.

Customer validation at the end Vs. Customer involvement from the start 

So with the Waterfall method, typically the customer really doesn't get involved until the very end of the project when everything is already delivered, done, tested and everything is signed off.

The customer really just has a hand in agreeing the requirements. But as far as seeing the end product, they don't get involved until the end. Whereas in Agile, on the other hand, the customer is involved from the very beginning because they get to see working prototypes in each sprint and get an opportunity to give feedback that can dictate how the project moves forward.

Sequential department focused versus collaborative. 

So with the Waterfall method, each phase has its own team of people that work on it and sign it off. So for example, when you do development, you have a development phase, whether that be for two weeks, two months or even two years, whatever the duration.

You have a specific team that will focus on that particular activity and once it's signed off it will then move on to the next team. So it's pretty much focused in departments of work.

Whereas with Agile you will have very small sprints. Development is done very quickly, then pass the code to the test team who then test it and then give their feedback immediately back to the development and project team. Then changes are made in development to update/improve and so on and so forth.

So in effect, you've got a very tight knit collaborative environment as opposed to a very much siloed off sequential focused model.

Suited for Defined Requirements vs Evolving Requirements

Suited for defined requirements, for example, a banking application versus evolving requirements such as a startup. What does this actually mean?

In essence, Agile is more geared up for a very dynamic environment where requirements may not be actually defined from the beginning. Whereas if you may have, for example a legacy banking application and you've got requirements that had been locked down from the beginning and you know exactly what you're delivering.

Then a more traditional Waterfall model or maybe even a V-Model will do for this manner may be the best thing to do.

Project development focused versus product focused. 

Waterfall method is pretty much based on delivering and following a very strict project methodology. Agile, on the other hand, is more based on coming up with the very best product.

Therefore you're looking for feedback from the customer to see if you're on the right track to deliver what they want. It's very much focused on the product itself rather than following a very rigid project methodology.

The Waterfall model is very good from a project perspective because you've got very clear milestones and you know exactly where you are and it's easy to estimate and allocate jobs/tasks.

However in Agile it's very much dynamic and can be a bit harder to project manage, but at the end you're hoping to get something which the customer is more happy with at the end.

Limited Communication and transparency versus the open model.

So with the Waterfall model you have very limited communication until you very much get to the end of the project. And when I say limited transparency, it effectively means once the requirements are agreed, you then go into project delivery mode.

Bare in mind, this could take two to six months and then by the end of the project, without having much transparency, you get delivered the end product and it's fingers crossed that the customer's happy with what they see.

For anyone that's spent any length of time in the software development or the testing industry, you know that it's very difficult to actually deliver exactly what someone expects without them seeing it up front, and this is where Agile has become quite popular in recent years.

It's been the answer to some of these challenges. Obviously Agile is not perfect in every shape or form, but it does address this aspect very well.

Simplicity for project management versus Organized chaos. 

Quite controversial, but hear me out first. The Waterfall methodology is quite good from a project management perspective because you've got very clear requirements.

These requirements can be mapped to test use cases, they can give you visibility of how long the project is likely to take, they can give you visibility of who's going to be responsible for producing each deliverable and it's very easy from a project management perspective to follow.

As opposed to Agile, which some people have used the term "organized chaos", which is quite harsh because obviously it does have some great values.

The problem is it's very hard to project manage in some aspects because it's very unclear exactly how it's going to evolve at the end product and exactly how many people you need to resource because you don't know if the project requirements are going to change significantly during the process.  So it's almost like a moving target.

Expensive requirement changes Vs fluid changes. 

What I mean by this is with the Waterfall model, if you decide to make some fundamental requirement changes halfway through the development phase, for example, three months down the line of a six month project, it's quite an expensive change.

Bear in mind that a whole project team could have maybe 20 highly paid professionals who are costing the project tens of thousands, maybe even hundreds of thousands of pounds.

Therefore for you to make a requirements change could mean going back to the beginning, making changes, getting it signed off, get all these people in a room to agree to these things, rolling out development testing again, effectively turns out to a very costly mistake to get the requirements wrong.

However in Agile, if you find that there's something not quite right in the requirements, you can simply make a very quick change rollout a new sprint and then you're back in business.

Related Questions

What is the difference between Scrum and Agile? I think it's more of a misunderstanding of Scrum. Scrum is actually a framework of Agile, so effectively they're one of the same thing, ​

There are other types of frameworks, e.g. Kanban which you may have heard of before, but Scrum is something which is really Agile.

Is Agile more expensive than Waterfall? Essentially this can be quite subjective depending on which project you're working on.

If you're talking about requirements changes, then definitely Waterfall can be very expensive in this process. Agile, again, it could be argued to be more expensive because you don't actually know exactly how much resources you're going to need to throw at it from looking at it at the beginning of the project.

As discussed earlier, this is because you don't have clear visibility of how it's going to transpire. In my opinion, the Waterfall is quite expensive because of the lack of flexibility. ​

You cannot be as dynamic and make quick requirements changes. So in my opinion, I'd say Waterfall is quite expensive, but there are cases to argue it on both sides.

What does Scrum stand for now? Scrum is not really an acronym. This is also probably a misunderstanding or misconception. Many people believe that Scrum is broken down into an acronym, but it isn't actually.

Scrum is just a word used to talk about this framework of Agile and doesn't necessarily mean an acronym. So essentially it doesn't really stand for any particular word or acronym at all.

So what is Scrum SAFe? Stands for "Scalable Agile Framework". Scrum SAFe is an implementation of Scrum. It's A scaling framework to take Agile to an enterprise level. 

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 (Click here to see which white-box testing technique is best), 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.


What are the benefits of Test-Driven Development (TDD)

If you researching Agile or methods to improve your testing or code delivery, no doubt you’ve heard of Test-Driven development (TDD). But why are so many people talking about TDD these days? Let's explore this and answer your specific question regarding the benefits.

What are the benefits of Test-Driven development? Fewer defects, speed of delivery, more cost effective, easier to test and more efficient code.

The reality is there are many benefits for TDD. Whilst these are the main benefits, it Is important to see why these are benefits and understand how this can benefit your business or career as a tester.

What is Test-driven development (TDD)?

TDD is developer centric method of preparing unit test cases ahead of development or design. The unit test cases effectively form the design of the code created.

This is different to traditional techniques such as the [waterfall method] or [V-Model]. This is because in these models the design is done up front, and test cases and code are driven by this design.

In TDD, the unit test cases will become the design for the code.

What are the pros and cons of TDD?

To truly answer this question, we need to break this down into a few sub-headings or bullets, because the list is quite extensive.


  • Speed of delivery
  • Fewer defects
  • Efficient code
  • Easier to test


  • Slows down development
  • Requires highly skilled testers
  • Hard to apply to existing development projects

Here is a breakdown of these Pros:

Speed of delivery: Once you have the tests laid out, the coding is easier to complete. This is a two-edged sword, as you will see later, because this can also be seen as a gift and a curse.

Fewer Defects: Because the tests are created up front, it is easier to test and eliminate potential defects. This is because the test team will think of the potential errors up front to tests, allowing the dev team an opportunity to cater for these issues up front.

Obviously, you will still find defects, but, if done correctly, it should greatly reduce them.

Efficient Code: Because you are focused on specific test cases, you will have more efficient modular code. Rather than thinking about the application as a whole, you can focus on that more focused modular code.

Easier to Test: Because the test cases are created up fron and form the design, you have a clear plan of tests before the application is created. It means that the testing process should be straight forward.

All the test conditions should be in place and ready to go as soon as the code base is available.

Here is a breakdown of these Cons:

Slows down development: This was the “Gift & Curse” that I mentioned earlier. From a project perspective the TDD method will help efficiency and speed. However, the actual development phase cannot start until the test are laid out.

It is still beneficial doing it this way, but just understand that there is a hit on your development start date using this method.

Require Highly skilled unit Testers: Because the testing is the center of this method, it is actually the tests that have to be high quality. What does this mean? Well, for example, you need to consider every potential test condition, before development.

A novice unit tester with little experience may be inclined to create a list of “happy path” tests, that may skim over many potential issues that the code can introduce.

Therefore an experienced unit tester with not only theory of the method, but experience of working in similar projects and understanding of the actual software that is being created.

For example, if you are building a new CRM system for the energy market. You will not only need a skilled TDD unit tester/developer, but one that has knowledge of the energy market to understand the service requests, market messages, etc. Are you with me?

Harder to apply to existing projects: If you have an existing, legacy system. The chances are you have processes in place already to test and develop it.

It is quite hard to transition from an older method, such as the [v-model] for example, to TDD. Not only will you need to change your processes, you will need to re-skill your staff, or bring in new staff to cover this. All of which will incur challenges and cost.  

What are the stages of Test-Driven development?

There are three key stages to TDD: Red, Green and Refactor. Each stage is as follows:

Red Phase: This is where the tests are created ahead of development, and arguably one of the most important stages in the process. If you miss something here, you will have a tough time getting the project to be successful.

Green Phase: This is where the code is written to address the tests created in the red phase. This is an ultra-focused process because the heavy lifting should have been done in the first stage.

Refactor Phase: This is the stage to tidy up the code. Such as making sure it is readable and maintainable. The green phase really focussed on making sure the code covered the test cases, which effectively have become the requirements.

Related Questions and Answers:

How is TDD different to ATDD and BDD? TDD, as discussed is focussed on creating tests up front. BDD or “Behaviour Driven Development” is, as the name suggests, a behaviour related methodology. It focuses on “Is this really what we should be testing?” as a continual question.

The BDD method makes sure that user stories that are built reflect actual business functionality. Whereas TDD is focussed at a unit test level, largely focused on code.

ATDD stands for Acceptance Test-Driven Development, it is highly collaborative methodology that encourages interaction from developers, users and testers. An acceptance test is created, from a users perspective and the code has to deliver based on this acceptance criteria.

The biggest difference between TDD and these methodologies is the stakeholders involved. TDD is largely a developer driven methodology without the interaction with other stakeholders.

How is TDD different to the traditional development process? With the traditional development process, the coding is done up front based on some ridged requirements, usually compiled by a Business Analyst (BA).

In parallel the test team would typically write test cases, to test that the code matches the business requirements. With the developers writing unit tests after the code is complete, to check that the code is fit for purpose and ready for the system test team to start their test phase.

With TDD however, this is flipped on its head. With the developers writing their unit tests up front, then coding. Once the code is done, it will be “Tested” to see if fails the pre-written test. Nowadays these are typically automated tests.

So there is a distinct difference here.

Is TDD Good for you? The decision to use TDD is quite subjective. As discussed it can help to make more efficient code, cut costs and focussed development iterations. Another benefit that has not been addressed earlier is the fast feedback to the developer to improve their code and help for a better quality release.

Benefits of TDD to software Testers

As a tester, TDD can help because each code unit will have a documented use case. Making it a lot easier to design and plan a suite of tests. With Agile testing it can sometimes be difficult to test, when you are asked “Test This”, only to discover that their os no documentation and your project manager presents you to a “moody” developer to get the “requirements”.

This method will help to give you some documented conditions and push back if you are challenged on how this test passed, etc. All in all it will benefit everyone on that basis.

What are the extreme programming advantages and disadvantages?



My Rating

Extreme Programming Explained (Click for reviews on Amazon)

Extreme Programming (Click for reviews on Amazon)

What is Extreme Programming (XP)?

Extreme programming is basically software development procedures designed and created to improve software quality as well as the ability it has to adapt to the ever-changing needs of users of that particular software.

The first to develop the Extreme Programming Methodology was Ken Beck around the mid and even late nineties. At the time, software used to manage the payrolls in large organizations known as Chrysler Comprehensive Compensation Systems is what he was working on. 

"Extreme Programming Explained" (Click to see reviews on Amazon) is a book he published in October 1999 and the book explains the entire methodology to others.

Extreme Programming and Agile processes of development have a few similar characteristics. One of them is that they both aim at producing frequent and iterative small releases during the course of the project. 

This allows both the clients and team members to review and examine the software project's progress during the entire process.

This type of programming prescribes a set of daily practices that developers and managers should adhere to. The main objective of these practices is to encourage and embody some particular values.

Experts believe when you when you exercise these practices, they will inevitably lead to development procedures that are much more responsive to client needs while still creating and designing software that is of better or similar quality.

The 5 Core Values of Extreme Programming

Here are the five core values:

  1. Communication

    Software development is more or less a team sport and no team can function effectively without proper communication.

    Team members need proper communication to be able to transfer knowledge effectively between one another. Extreme Programming stresses the importance of proper kinds of communication.
  2. Simplicity
    XP is all about using the simple things that have proved to work. Why simplicity is a major factor to avoid wastage so as to only do the things that are absolutely necessary.

    An example of the simple things XP stresses over is keeping software designs as simple as you can which makes maintenance, support and revision so much easier.
  3. Feedback
    Constant feedback concerning the previous efforts of the team allows the team to clearly identify the areas that need revision as well as improvement.

    Constant feedback also greatly supports simple designs. Your team builds what they need to build, gathers constructive feedback on implementation and design, and then make adjustments to your software product as you move forward.
  4. Courage
    Kent Beck in his book "Extreme Programming Explained" defines courage as the preference of action based principles whereby the results are not harmful to your team.

    For one to raise organizational issues that involve the effectiveness of the team. For you to stop doing the things that don't work you'll need the courage to try something else. Finally, you'll also need courage when accepting and acting on feedback especially when it's negative.
  5. Respect
    If your team members want to communicate with each other effectively, accept as well as provide constructive feedback and work with each other properly, and cohesively work together, then they'll need to learn how to respect each other as a whole.

Advantages of Extreme Programming

Here are the advantages of Extreme Programming:

  • Robustness: The fact that the power of simplicity is leveraged is a big advantage. The way developers take their time on small iterations and software pieces resembles completing jigsaw puzzles.

    This approach creates software that works faster as well as one that lacks many defects. Bug detection is guaranteed when regular testing is done during the development stage.

  • Resilience: When requirements remain static then the traditional means of programming are advised.

    However, that's not how the real world operates. Things like new business opportunities completely change requirement dynamics.

    This type of programming accommodates requirement changes by getting and storing the user stories from the start and also from the constant feedback during the course of iterations.

  • Cost Saving: XP helps in trimming unproductive activities in order to reduce frustration and cost. Needless paperwork is avoided in order to allow developers and programmers to concentrate on coding instead of needles time wasting.

    The fact that changes are made based on client feedback during development stages keeps overall costs low.

  • Employee Satisfaction: The fact that XP reduces the importance of individuals during the development process helps increase employee retention and satisfaction.

    This type of programming is all about value-driven approaches which set fixed work schedules without concentrating on overtime.

Disadvantages of Extreme Programming

Here are the disadvantages of Extreme Programming:

  • Difficulty: This is technically a tough software practice so convincing developers and programmers to adopt it won't be easy. It requires customer devotion as well as lots and lots of team discipline.

    Its life cycle has very many different changes which mean that those who manage this type of software projects are bound to be faced with numerous difficulties.
  • XP Relies on Very Many Factors: This is basically a minimalist process. Its lack of vigor is made up by the number of practices involved.

    The project has a high risk of failure if something goes wrong. This happens to be a very big disadvantage when it comes to this type of software development. The fact of the matter is that extreme programming is a highly risky endeavour.

  • Code Centric: This type of programming methodology is code-centric rather than design-centric. This can prove to be very tiring when larger software projects are involved.

    XP is also very time consuming and has a lot of refactoring involved in its procedures. Test coding is also quite difficult in this programming process. This is largely due to defects that have not been documented well and codes that haven't been structured well enough.


External Programming has made a very big contribution to the software development world. Many teams involved in agile projects use very many different types of tactics and helpful methodologies.

This is one procedure that is highly useful for all the software developers and programmers in the agile realm. The fact that it focuses on practice excellence makes this procedure one of a kind and if you're involved in this type of software development then you should definitely try out this procedure, You won't regret it. And now you know.

Difference between a Waterfall Iron Triangle & Agile Triangle?

What Is The Traditional Iron Triangle?

What is the difference between the Waterfall Iron Triangle and the AgileTriangle? Let's start by defining what the traditional iron triangle really is. We all know that software projects in agile always have goals.

These goals include; what the project is expected to produce, the project's delivery deadline and the budget of the entire process. Managing these three components can prove to be quite difficult sometimes.

In 1969, Dr. Martin Barnes proposed the original iron triangle. In this approach product development is done using a waterfall approach which means that time and resources are variable while the scope is fixed.

Software teams using this approach will have to determine the project's scope by defining product requirements before they are able to start the project.

The schedule and resources are variable and are determined based on the fixed scope, The iron triangle's main objective is to provide software product teams with appropriate information in order to allow them to help the business by making effective trade-off decisions. 

An example is when teams are halfway through the project and they come to the conclusion that they might not hit the release date while using a fixed scope, the only options they have available to them when in this scenario is;

  1. Time (accepting a later release date) ​
  2. Resources (an addition of other workers to the project).

What Is The Agile Triangle?

The Agile Triangle is basically somewhat of an extension of what the traditional Iron Triangle is.

Jim Highsmith, the Agile luminary is originally the one that conceived this idea, where he claimed that the dilemma many agile teams are usually caught up with is that on one side they're being told to be adaptable, flexible and agile while on the other side they're being told to conform to Iron Triangle's pre-planned framework of cost, schedule and scope. Essentially they're advised to being as flexible as they can be.

Teams in the Agile realm are made to concentrate on the project's release rather than letting the Iron Triangle principles restrain them. So, using Jim Highsmith's school of thought, the Agile teams' main objective is to release the product. Everything else comes second to that, especially when it comes to Iron Triangle constraints.

The Agile Triangle collapses the Iron Triangle's three end points into one vertex The rest of the end points left such as value and quality will be the ultimate goals' definition, mainly because they need the most attention due to the fact that stakeholders usually feel that they're the most important. The Agile Triangle is trying to bring the traditional Iron Triangle way of thinking into the future.

Why The Need For The Agile Triangle?

The need and importance of the Agile Triangle are best described by Jim Highsmith when he stated that agility is all about being flexible when delivering customer value, which means that measuring performance using the traditional Iron Triangle principles of scope, schedule and scope can't possibly be effective if that's what you want to achieve.

If you want to be the most flexible you can be then focusing on quality, value and constraints, which is essentially the Agile Triangle, is what you'll need to conform to.

The difference when Agile Triangle methodology is practiced can be seen as follows:

  1. Scope Versus Value
    The scope of the project is important. It defines as well as outlines your project. One would think that if you are in Agile management your project scope should also include value, wouldn't you? In fact, your project value includes the scope at different levels and not just at the definition. Even though agile management can offer a lot of flexibility, too much of it isn't always the best thing.

  2. Schedule Versus Constraints
    Project schedules are usually fast and hard rules that you'll need to stick to, however, change will always occur. Defining constraints will help you with schedules and timelines within that particular project. The Agile triangle strategy concentrates on redefining scheduling rather than utilizing constraints.

  3. Cost Versus Quality
    Is the project's quality really represented by how much the project costs? The agile triangle school of thought is that quality should not be the project's end and only result. You should rather be concentrating on producing your desired quality and effect using flexible overall cost structures. Simple as that, so to speak, however, it's usually never easier said than done.

Is The Agile Version Better Than the Conventional Method?

As alluded in the previous sections of this article, the project requirement in traditional projects is determined upfront with a precise level of detail. Fixing a particular scope, time and cost help in setting your project up for failure.

This is due to the fact that when your timeline begins to approach its end or the budget looks to be running out you'll inevitably be forced to have to de-scope something which means leaving inventory behind and delivering less than what was originally specified upfront.

The principles that the Agile framework uses turns all this upside down, by avoiding to concentrate on specified upfront details which usually cause the unexpected end results or products that deliver less than what they were supposed to. 

The main objectives here is producing a vision that is well defined, decomposition of that vision into themes and then elaborating more specific feature details based on those themes' priorities.

Finally, the features with the highest priorities turned into stories while the stories with the highest priority turned into technical designs which all this then helps in the production of properly working software. 

This is the major reason why most IT professionals in Agile software development think that this technique is the better option.


When it comes down to it, Agile triangle edges out the Iron Triangle as being the better and more effective management and working approach in today's software development world. However, if you can fully understand both the approaches then the better for you for that will only help to make you a more efficient worker. Hopefully, this article has opened your eyes to something you may not have realized just yet.

What is Most Important According to the Agile Manifesto?


In February 2001, a group of renegade software developers met in the mountains of Utah and came up with the Agile Manifesto, a set of rules and principles that would go on to revolutionise how software is developed at the world’s leading technology companies.

Today, Silicon Valley’s influence is pervasive, and a lot of the success is easily attributed to the wide-scale adoption of the Agile Manifesto.

Agile is no longer just for tech geeks, and we, lay people, can no longer afford to be ignorant about it. Agile principles are creeping into wider use in all other industries, for example they have recently been adopted at companies like Walmart and Verizon.

What is the Agile Manifesto? 

In the time before agile, software development was a very formulaic and step by step process.

When someone decided that they wanted a new software created, they developed a very clear specification of what they hoped to see. Developers then worked backwards from that list come up with the necessary steps in the development process.

They then set about the process of creating the software. This process was largely stifling and slowed the pace of innovation. Critically, it had a high failure rate!

Recognising that something needed to change, leading developers organised a three day retreat in 2001 to brainstorm ideas on how to improve the software development process.

The Agile Manifesto is what came out of that retreat. It was signed by everyone who attended and codified the four values and 12 principles that would inform the new way of developing software in the future.

What are the 4 values of the Agile Manifesto? 

The Agile Manifesto begins by outlining four value statements that indicate relative priorities for agile developer.

Each value is two sided statement, on the left of each statement are the things that are more valuable, on the right are the things that are regarded as less important to achieve.

These values are:

  • Individual & interactions, over process & tools
  • Working-software, over comprehensive-document
  • Client-collaboration, over contract-negotiation
  • Response to change, over following of a plan

No one value statement is described as being more important than the other. All the statements are underlaid by the same aspiration, to prioritise output over process in developing software.

The values in the Agile-Manifesto are designed to create a software development process that optimises functionality for the end user rather than having a perfectly laid out and compliant development process.

For example, the fourth value makes it very clear that if there is a pre agreed plan and events outside of this plan happen, you have to ditch the plan and continue developing the software based on the unplanned events.

What are the 12 Agile Manifesto Principles?

The most important part of the Agile Manifesto are the value statements. The twelve principles were written as logical conclusions that follow from those values. 

They provide you as the agile developer, additional clarification on how the prioritisation defined in the value statements works in practice. Each of the 12 principles speaks to a different stage in the project-management cycle. You cannot help but be impressed by the precision and simplicity of the principles.

One principle is: Working software is the primary measure of progress.

All the other principles are equally brief and unambiguous. If you are working in an agile team, the principles give clear directives on how success is measured, the acceptable means and frequency of communication (in person and daily), and the pace of work. Crucially an agile, project is never done, and the pace of work should stay high.

What is agile SAFe? 

One obvious limitation of Agile, is the principle we referenced at the end of the last section: Agile processes promote sustainable development.

The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

Working in indefinite high calibre process is a very tough ask. it would be impossible for any human team to work indefinitely and to a high standard without quitting or dying! It is for this reason that The Scaled Agile Framework or agile SAFe was developed.

You can think of agile SAFe as the version of Agile that people can actually do! It is a framework for delivering excellent outputs quickly and sustainably. It is agile, but with a reasonable bound on the time and effort expected.

It is the adaptation of the Agile Manifesto to creating agile SAFe that has enabled the increasing popularity of agile in mainstream business environments.

This is because agile SAFe is written in the language of business and can be time and budget bound. Crucial factors for evaluating the success of a commercial project.

What are the core values of SAFe?

There are four core SAFe agile values:

  • Alignment
  • Built in quality
  • Transparency
  • Program execution

SAFe is more of a project manager’s interpretation of agile. Perhaps unsurprisingly then, while you can list the four values as four short words and phrases, the explanation behind each value runs into a few paragraphs in length.

The essence of the SAFe agile core values is that there must be alignment of strategy and operations for any SAFe project to succeed.

Everyone must be on the same page. Regarding quality, all inputs should be of high quality. This makes sense, you cannot design high calibre products with bad inputs, hence built in quality.

The third value of transparency is about having frank and open communication on the project team, and maintaining visibility.

Finally, the fourth value of program executions, means that SAFe teams should retain a focus on doing.


We hope you enjoyed learning more about the Agile Manifesto and the core elements driving the approach. Agile is increasingly the working method across several businesses, including in non-tech teams.

This means it was really important to write this as an entry point for the average reader who might soon be working in an agile environment, or studying Agile topics, like the Agile Triangle, and many others.

Let us know your thoughts on the Agile Manifesto in the comments section. Do you think agile is effective as a general project management tool, or do you think it works best when restricted to software development projects? If you enjoyed this article, we ask you to please share it widely.

Skip to toolbar