Category Archives for "Agile Testing"

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?

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" 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.

Need Certified Agile Tester Exam Sample Questions?

Where can I find Certified Agile Tester (CAT) Exam sample questions? 

Might this be a question you've been asking yourself lately? Well then, you're in luck, for you happen to be at just the right place.

This article will effectively answer that question and much more. The Certified Agile Tester Course is organized by the International Software Quality Institute (ISQI) of Germany.

Unlike most of the Testing Certifications such as ISTQB and the like whereby the course material is normally prepared by the training institutions involved, with the Certified Agile Tester, the material is prepared by the ISQI itself. 

This, in turn, means that no matter where you're sitting the exam, the course material will be the same for all the course takers.

The course material the International Software Quality Institute will provide you with will have everything you need, from the Agile Methodology Manifesto introduction to sample questions.

However, if you are looking for more sample papers, than are provided on the course itself, the selection of sample papers are quite limited, when compared to other qualification like the ISTQB Agile Extension, however, you can contact exam providers, like SQS, and request some sample papers.

What is the ISQI Certified Agile Testing Certification (CAT)?

Agile Testing slightly deviates from the more traditional regimented tests. This is because it needs to be adaptive and flexible in order to effectively adapt to the frequent feedback iterations.

The Certified Agile Tester by ISQI, commonly known as "CAT", has come to be recognized, by the software test professionals looking to work in the Agile environment, as the primary international qualification. 

This certification process is a very rigorous one which combines theory and practical exams as well soft skill assessment.

The Certified Agile Tester Exam is split into 3 different parts.

  • Soft skill assessment concentrating on your capacity for teamwork
  • An open question examination that is used to demonstrate your profound theoretical knowledge
  • And a practical section where the testing skills of the examinee are tested.

The paper-based exam mentioned above is separated into 3 phases. The exam's passing grade is sixty-five percent. Participants should at least score fifty percent in both the written and practical exam in order for them to pass.

Non-native speakers, upon request, will be awarded thirty minutes extension.

Will The Agile Testing Book by Janet Gregory and Lisa Crispin Help You Prepare for this exam?

This book is highly recommended and should be read by every agile project tester, mostly because agile projects normally try to avoid specific roles.

The book begins by laying a little groundwork by attempting to effectively define what agile testing is all about.

In the second part of the book, the authors dwell on the organizational changes that will occur after testing while part three is undoubtedly the centerpiece of the entire book.

It is mainly designed around 4 testing quadrants initially conceived by Brian Marick, the co-author of Agile Manifesto. 

Because of these quadrants, Gregory and Crispin are able to cover a wide range of topics which include API, UI, reliability testing, usability, stress, and performance.

The fourth part of the book mainly deals with automation and this happens to be a topic that all agile team members should have in their minds. One section is particularly quite interesting and that is the part of the barriers to automation discussion.

Overcoming the resistance brought forth by these barriers is made easier once you've understood the advice provided in this part. In the final part of the book, the authors end it with a critical success factors short list.

What are the Agile Testing Quadrants?

Quadrant 1: Technology (Support Team Testing)

This quadrant covers tests such as API tests, Unit Tests, Component Test and Web Service Testing. Basically, this area concentrates on Automated testing. The main advantage of this quadrant is that it provides tests that improve the design without affecting functionality.

Its main objective is to use legitimate source code management skills as well as an integrated development environment to improve product quality.

Quadrant 2: Business (Support Team Testing)

This part dwells on Manual and Automated Testing. The tests it covers include Story tests, Functional Testing, Simulations and Prototypes. This quadrant provides you with a way to formulate the appropriate set of questions that drive tests which are aligned to your business.

Quadrant 3: Business (Product Critique Tests)

This quadrant mainly deals with Manual Testing. The tests it covers include Scenario-Based Testing, Exploratory Testing, User Acceptance Testing, Usability Testing, Alpha/Beta testing and Acceptance Testing. It's basically all about effectively evaluating the product.

Quadrant 4: Technology (Product Critique Testing)

The final quadrant mainly deals with Automated testing and the tests it covers include Security Testing, Performance and Load testing and the like.

Manual Testing vs. Automated Testing in Agile

Most experts will agree that both manual and automated training play a big role in the agility environment and are both very important. 

However, the type of testing you're doing is what will largely determine what the best choice will be. In the book by Lisa Crispin and Janet Gregory, they describe four quadrants of testing.

The first one deals with automated test efforts that include component and unit tests. These are usually done by the developer way before the initial code is written. 

The second quadrant may be manual or automated testing and is done by the testers as well as developers. These are functional tests such as prototypes, simulations, and story tests.

In the third quadrant, they involve some manual testing which includes usability testing, exploratory testing, alpha/beta training and acceptance testing.

Automation, in most fields, brings forth the benefit of reduced costs and increased productivity. In the agile software development arena, it's actually pretty vital.

They basically go hand in hand. You can do without manual testing in agile, however, you can't do without automation which in turn makes automation much more important than manual testing.


While this certification builds its popularity, it is a challenge to find as much specific resources, however, hopefully this article has provided some ideas and preparation needed to help you.

This certification was meant for those test practitioners that are looking to enhance their abilities when performing tests involving agile projects The Scrum flavour is the main focus of the entire course of agile development.

It's a course you just can't afford to do without if your a software tester or developer looking to make your way in the agile environment. It's both world renowned and well respected in the agility software development industry.

Is this What You’ve Been Told a User Story in the Agile Methodology is?

What is a User Story?

Simply put, a user story is the smallest unit of work in the agile framework that serves as a software system requirement.

Here is an in depth look into User stories and Agile characteristics:

What is an Initial User Story

Initial user stories are much smaller and basically define the interaction between the end user and the system in certain usages and scenarios.

Two types of Initial User stories exist: Formal and Informal.

  1. Formal User Stories:
    These are detailed sentences that help programmers identify the actors (team leaders, members and product owners) and their business value as a requirement

    A formal approach is usually applied with the template:
    e.g. As a (role) I want (something) so that (benefit).

    For example: As a reporter, I want a transport allowances so that I can travel and cover stories.
  2. Informal User Stories: -These are usually high level stories with no specified format in the actual story card. Their simplicity with no rules makes them easily distinguishable from other Agile stories.

What is an Epic?

Looking at the bigger picture after writing your user story lies an epic. This is a much broader chunk of work with a common objective.

A product owner can write a user story that seems really simple at first and puts it under a single sprint. In real sense, it becomes impossible to finish it in time and is then carried forward as an Iteration backlog.

The big user story now an epic, needs to be split into smaller user stories to obtain a better estimate of the sprint

Both the epic and user stories are used to classify the amount of work to be done. Epics differ from each organization.

Giant tech companies have bigger epics as compared to smaller companies whose epics could probably be done within a single sprint.

It’s also important to mention features under agile methodology. Features refer to the strategy layer that user stories try to accomplish.

An epic comprises of several features within which also comprise of a couple of user stories.

What is a Theme?

As a product owner, you may choose to diversify and change to other aspects to maximize on profits. A theme a large area of focus usually assigned to different teams.

A theme may or may not include epics of related proportions. The user stories in a particular team may be totally unrelated thus spanning the organization.

In the same way epics are made of different user stories, a theme is made of different epics. It is important to also mention Initiatives. 

Just like features, initiatives lay the foundation of epics driving them towards a common goal.Initiatives take much longer to complete than epics. Initiatives have structural designs that clearly define the epics and their time frames.

One major characteristic of a theme is that its overly ambitious. It mostly defines the product owners’ dreams and goals in partnership with the stakeholders. They sometimes inspire the teams to create reasonable epics in regression to the original Agile idea.

The themes are used to organize the epics for better processing.

What is a User Persona?

To fully understand what a user persona is, a background check into the world of marketing is in order. Remember a developer cannot create a program without actually knowing about the consumer base and their needs.

In software development, there is a team responsible for researching related topics on the project and give feedback to their teams. This data obtained which usually contains a list of pros, cons, goals and complications are arranged in a manner that reflects a data persona.

A user persona is that a character that is a representation of a user who will interact with the product you are passing. It may be a program, an app or another software entirely designed to target how best your product will perform in the market. 

If your product is a web-based feature, it is expected that it will receive more than one user. Therefore, it is advisable to create more than one use persona to adapt with the increasing number of traffic inside your website.

As mentioned above, a user persona’s initial stages of development usually comprise of market research. These include the use of prototypes that are released to beta testers who have already subscribed into testing of the persona. 

The beta testers give out their general feedback of the working of the program on interviews or focus groups where they share their opinion. Areas of improvements are shared and worked on in the tasks to come.

What is an Acceptance Criteria?

According to leadingagile, they are a group of conditions that need to be met to satisfy and accepted by a user or customer.

They are one of the most important things to get right, from the start, so you know when you have done enough testing to exit the process.

Final Words on User Stories

The incorporation of user stories into software development has made the task more human friendly as opposed to other impersonal methods. Its launching is more thrilling as it contains actual conversations of the user requirements that a client demands.

As part of the team, you may need to complete a user story diligently and fast since anyone in management including the stakeholders can write a user story and add to your collection.

If not properly handled, user stories can pile up to form company backlogs which are enemies of progress.

Before you go, lets delve into another buzz word in Agile, ATDD...

Really? Is this What ATDD in Agile Stands for? The inside scoop!

Really? Is this What ATDD in Agile Stands for? The inside scoop!

What is ATDD?

One framework that has been gradually rising is ATTD, which stands for Acceptance Test Driven Development.

What is ATDD?

ATTD is an Agile based developmental framework that involves communication between the business stakeholders, customers, developers and down to the beta testers. 

At the same time, the user stories once executed are passed through several detailed acceptance tests that check on how the system will perform as per the user’s point of view.

The difference between this tool and Scrum is that the latter’s User story is scrutinized by the developer and the product owner and run against several Acceptance criteria to check on its overall functionality. In other words, the tests are done immediately the user stories are written prior to any development work.

Is it also referred to as Story Test Driven Development (STDD)?

In order to clearly define what an STDD is, it is fundamental to learn about the Test-Driven Development (TDD). This methodology involves a short development cycle that is usually repeated until it passes the required test criteria.

It can be very tiresome since the first test is usually targeted to fail and with the subsequent tests geared towards software improvements.

The Story Test Driven Development is subset of the TDD that focuses on higher level acceptance tests. So, in a way the collaborative framework is also sometimes referred to as a STDD though less commonly.

The STTD comprises of four major key components namely:

  1. System specifics: - Written in HTML the document briefly describes how the software is expected to function.
  2. Acceptance Test Fixture: - This reads the system specifics Html to ascertain that the specifications are adhered to
  3. Unit Test cases: - As the name suggests, these are tests specifically run as a unit to make sure the software runs as intended.
  4. Story test results: - With all said and done, a summary of all the acceptance tests and their results are recorded here.

What about Behaviour Driven Development (BDD), is it the same?

According to gaboesquivel, BDD is a subset of the TDD. It is totally different from the collaborative framework in that its software operates on principles like, designing and programming a unit test and ensure they fail before finally implementing and verifying the implementation of the unit.

BDD generally gives a consistent customer-based reception allowing for the inclusion of everybody involved in the process whether they are conversant with developer options or not.

What this means is that as a customer, your needs will be put first before anyone else. Another difference of the BDD is that it focusses on how the system operates whereas the framework in discussion drives at carefully meeting the acceptance tests needed for efficient software functionality.

The tool structures that support the BDD include the JBehave and RBehave developed by Dan North. In these structures, the framework specifies and executes the tests for each scenario bearing in mind the schematics of the scenario.

What are the benefits of ATDD?

The long chain of activities involved in this framework finally pay off in the following ways.

  • Quick solutions to problems arising: - the world of designing and developing software is challenging and filled with setbacks. As such, it requires a tool that can instantly solve some of these problems. It accomplishes these problems by sharing the design and testing it in its early stages
  • Simpler to Manage: - Unlike TDD, this framework is known to incorporate everyone into it meaning, smaller user stories will be assigned to each team to be completed during a shorter timeframe. Smaller builds are usually easier to monitor and manage especially in distribution of resources.
  • Customer focused: - this design puts the needs and preferences of the customer above all else. Through prior research within the market, developers have it easier to do their work especially with the needs of the consumers in mind.
  • Bridges the gap between different teams: - According to qasymphony, it improves the efficiency in the development process. It's collaborative efforts initiate communication between the developers and the stakeholders alike thereby closing the gap.

What are the common Pitfalls?

Like every other software framework, the ATDD isn’t lacking in a few cons:

  • This method is geared towards the customer’s satisfaction which can be a a huge blow to the product owner especially if their interests don’t align.
  • The framework is designed to operate under specific tools like Cucumber that requires mastery and constant practice. As such, this will deter the primary objective of the framework to improve on the collaborative interaction between the stakeholders and developers.

Final Words on ATDD

ATTD is becoming more popular for simple reasons like anyone being able to write and run the acceptance tests. In the ever-digital competitive world, it offers more dynamic and efficient improvements to your product throughout its automation features.

If you can use a method that will get you faster results, why not take the chance?

Should You Really Be Using Risk Poker in Agile?

What Is Risk Poker In Agile?

Risk Poker is an Agile method for risk based testing. Testing is a way of mitigating risk and in Agile Risk based Poker is a method to handle this.

Planning poker is a fun game based method that oversees user story points matched with related functional elements within an agile project.

Risk poker, on the other hand, is a risk based testing method, similar to planning poker, with the difference being, identifying key risks rather than estimation on user stories.

What is Risk based testing?

Software developers have it hard in their work. Their programs often undergo a lot of scrutiny before getting released into the market. Testing is a method used to identify product defects and software problems which are then returned to the developers. The criteria used in testing is solely based on the owner’s specifications.

Products are often at a risk of failing if they do not satisfy the consumers hence a product risk directly related to its failure. A risk based testing is an agile based approach that oversees tests conducted on a product based on the chances that it may not perform well on the market. This may be as a result of defects in its software coding or simply put as bugs or just shift and preferences in general consumerism.

Pressure from the market to deliver the finished product based on the fixed time frame as per the Iterations could also be another factor for product risk failures.

A risk based testing approach also determines the overall impact of failure and the importance of the consequences that may arise from the risk of failure.

What is Product Risk Management?

Different methodologies exist in identifying the gross mismatch between the market expectations and the finished product. Product Risk Management tops the list as one of the most effective way of managing the set of failures that may arise.

Proper analysis of the influencing factors that may result to the negative output of a product constitute risk management.

It is sometimes referred to as Risk mitigation because management tends to control the severity of the outcomes. Risk management is a lengthy process and often comprises of 6 steps.

  1. Identifying the two dimensions of risks: -by focusing on their strengths and weaknesses.
  2. Classification: -organizing and categorizing risks according to the criteria of your own choosing.
  3. Quantify: - you may need to use probability vectors to properly assess the veracity of the impact each risk poses.
  4. Plan: - this involves coming up with quick solutions to the already identified set of categorized risks.
  5. Implement: - you may need to put your idea solutions into good use at this stage and run them.
  6. Reiteration: - the need to repeat the analysis to make sure old risks remain buried and find out new ones.

What is a Product Risk Matrix?

After identifying the most crucial risks to be tested and quantifying them, rough estimates are drawn and numerical values assigned to their impacts.

A product risk matrix is a mathematical representation of the numerical values expressed divided into 4 different regions each representing a different level and type of risk involved.

Other mathematical based methods of graphical representation such as the use of Histograms and tabular like drawing of often complicated values aren’t as appealing as a risk matrix.

One advantage it holds over the rest is that it is very simple and easy to decipher. The horizontal axis can represent the impact of the risk while the vertical axis can represent the chances of occurrence of the risk involved.

As a result stakeholders may not need to rack their brains trying to figure out exact figures as seen in graphs.

What is the objective of Planning Poker?

Planning poker specifically aims at gathering feedback from all the team members on which way to deal with the project backlogs.

Planning poker also eases the overall estimation process by resizing an already existing story before its implemented. For overall success, you need to have self- control in order to determine when best to quit even if you are winning. Setting a limit becomes a bother especially if you are losing with the hopes of performing better.

In Scrum poker, how hard a story is doesn’t have a definitive method of determination. A dynamic process exists with non-definitive methods like vagueness in level of risks and uncertainty involved.

Contrast exists when defined values like countable figures specify planning poker. The most common poker method used is the Fibonacci sequence of numbers which each team member picks to represent a story value. Other examples include

What is Protection Poker?

The internet world is prone to security risks and unauthorized entry into organizations encrypted files. A method to counteract these illegal activities by malicious hackers is an agile based security risk game called Protection Poker.

The security based game is interactive, collaborative and comprises of a collection of ideas sharing past experiences that offer a better exposure for software security.

Brainstorming for solutions to patch up bugs and defective software coding as an overall risk is also included in the game experience. Team members are required to think like a software attacker and close up any breaches within the product’s network.

Final Words on Risk Poker

Quality service delivery is key in the final product, hence the reason we have the Agile Manifesto, for example. A substantial amount of funding should be set aside to assess and analyze the level of risks involved. It may not be possible to completely analyze every risk and test every aspect of a system as per the orders of the stakeholders.

Methods like Risk Poker, a light weight approach crucially takes care of this problem and gives you a more in depth analysis of the impacts of failures, should they arise. All in all, not infringing on your limited budget.

Before you go, lets look at some key Agile Sprint activities...

7 In Sprint Testing Activities You Need to Do to Get Paid

in sprint testing activities

Introduction - The 7 In Sprint Activities

The mobile and web applications development sector has never seen a better platform than the Agile based methods of software development. If you are new to this technological advancement, here is an in-depth analysis of one the methods and terminologies used: Sprint testing.

A sprint goes hand in hand with Scrum as an agile approach to development which is extremely difficult to master. It’s a form of Iteration that involves quite a number of activities and if you aren’t careful to its approach, the overall structure may collapse. Here are what agile testers need to do in a sprint before the project can be termed as 'done’.

1. Test Estimation

Agile may have fully changed software development but testing software proves quite a challenge. The first step usually entails making a rough estimation for each user story created. 

This involves a detailed time account for all the steps involved that provide an overall scope for the entire project. This may include:

  • Identifying references to different user stories
  • Analysis of the requirements of the story
  • Sizing the whole story by giving proportional values depending on the amount of work to be done

A sprint is usually a development cycle. The scope of the estimate should cater for all challenges that may be encountered within the process. Many agile developers often complain about the possibility completing all the testing in one sprint especially if the sprint also includes backlogs from previous designs.

2. Design Test Cases

If you are a product owner, you would definitely employ the best team to meet your conditions and specifications. Test cases simply outline whether the system being tested meets the variables and requirements of the stakeholders.

A common misconception during the design of a test case is that a user story is a requirement. A test case is created manually with regards to the accepted criteria. Each and every product backlog goes into the sprint backlog where it is analyzed. This includes items like epics, features and user stories.

3. Work Closely with your team

Agile methodology is not to be confused with the traditional waterfall approach that run test checks at the final stages of the software development. Instead testing is done through each development stage.

This may increase product backlog as coding may be prone to bugs which may require technical support and knowledge acquisition.

High level descriptive functionalities are often specified under the user stories. Its complexity may prove quite challenging and its therefore important to grace the team with your presence to offer technical support and smoothen the whole process.

You may need to outline the user stories as the simplest increments that need to be built upon. Once the team understands this, you may need to reiterate the features which are usually too general to build. Using this knowledge, high level features need to be refined greatly to be done under a single sprint if possible.

4. Defect Management

Sprint testing often aims at ensuring the final program is devoid of any glitches and runs as smoothly as intended. This may be achieved through defect management which is the ultimate software debugging process.

Simply put, it’s a process that pin points to the exact bug and its location in a program and developing ways to fix it

Defect management involves four easy steps

  • Detecting the source of the error
  • Defect report writing
  • Debugging
  • Preparation of a defect list that includes all defects identified and fixed

5. Add Value in Stand-Up Meetings

Don’t always be the member of the team who is always absent in important group gatherings. It is important to always show up punctual to daily stand-up meetings to review the overall progress report.

In Agile, silence Is never golden. Share your thought and ideas on how to tackle the most troublesome processes encountered. Your focus should be purely on ways to complete backlogs and new challenging projects.

For instance, do not focus on what you have already achieved or what you are intending to achieve as this will come off as a bit of a show off. Instead, psych up the team and provide solutions to general problems they may encounter.

6. Have a clear exit criteria

Even before you start testing, it is important to have a clear, and agreed exit criteria. The "agreed" part is probably the most important. This means you know when you can exit the process, without going round in circles, continuously raising defects, and re-testing.

An example may be, maximum of five sev 3 defects open, after test completion.

7. Work Closely with Stakeholders

One of Agile’s tenets is its dynamic ability to welcome change. You may need to learn a few details of the task at hand through working closely with the responsible authoritative figureheads.

These may include additional funding in cases of limited resources. Coming from a traditional based developer methodology, you may need to learn about the agile based software. There isn’t anyone more knowledgeable regarding your line of work as the stakeholders.

Conclusion - In Sprint Activities

As an agile tester, negative afterthoughts like the sprint being too short should be discouraged. Planning and collaborative effort is usually key to these kinds of problems.

Trying to mitigate problems during a sprint test is usually a bad idea as the problem will keep on recurring. To ensure you reap the benefits of your work, you may need to simply create test automations that will check on regression and performance during each sprint.

What is sprint zero in agile?

Sprint Zero - Intro

The Sprint Zero idea, like many things on planet earth, is often used and abused. So, what is Sprint Zero in agile? Sprints are agile's way of breaking down project management processes into smaller manageable parts in order to simplify the entire procedure in general.

Sprint zero is what is usually known as "project before the project".

This concept is proving to be so effective until large organizations are starting to apply these agile principles across all project management departments.

With that said, as agile demand grows, so does the mystification around the Sprint Zero term. In its most simplified meaning, it's basically the application of Scrum Sprint frameworks to pre-planning procedures for a project.

This pre-planning procedure manages to become a project within itself during the course of the Sprint. 

The Scrum school of thought is of the belief that every sprint should produce potentially viable value.

What's the Sprint Zero Concept?

Sprint Zero's main goal is to produce some viable value that can be utilized by the team that follows suit. However, the question of what the concept of the entire procedure is can be a very tricky one to answer.

Most software and management leaders tend to demonstrate how much they understand agile scrum concepts and will usually want to run all their other systems under Sprint from day one, however, they're probably going to be unable to produce even a single releasable feature.

The name zero comes from the failure to produce this feature which is used to tell stake holders to expect nothing from the sprint as it is a Zero Sprint.

Zero Sprints are generally required to keep designs minimal, create project skeletons (including all the research spikes), developing a tiny number of stories until completion and be lightweight as well as low velocity.

A small number of stories should already be in the backlog before the beginning of the Sprint Zero process if you want this approach to be a success to you. This few number of stories will act as catalyst for the Sprint to produce results that can be demonstrated.

How to Get the Most Out of Sprint Zero

If you want to know how to get the most of Sprint Zero you first have to know how to conduct the procedure effectively.

The best way for you to understand this process is to know that for you to have a successful Sprint Zero process you'll have to be ready to begin from Sprint One.

"Ready" in this context is a bit of a vague term because readiness does not mean the operation procedures that are in place are available. However, this aspect has hopefully been taken care of. What readiness basically means is that development can occur in the said environment. A few do's and dont's if you want to conduct a successful Sprint Zero procedure:-

  • Don't take more than a week
  • Do keep your systems lightweight and stay clear from big design principles
  • Don't do more than what is required of you in the first stage just so you can produce a successful kickoff
  • Do emphasize a team building culture and always try as much as possible to get all your team members involved in the work.

Common Pitfalls of the Sprint Zero Process

Here are some of the common pitfalls of sprint zero:

  1. Harried designers with rushed designs:
    When developers and designers start at once, in agile projects, it sort of almost has the feeling of starting a run on a treadmill when it's already on the highest level without even warming up first.

    You'll constantly be at the risk of making a fool out of yourself by falling off. This "everybody begins at once" format places huge pressure on developers and designers to simply just complete their work.

    In such scenarios they'll most likely tend to rush their decisions without thinking about them too critically. This will, in turn, result in the production of unpolished, uninspired designs.
  2. Unvalidated Design:
    Software consultants and practitioners always have to validate their designs with 2 different groups. Their clients have to approve them and its testing needs to be done using their target users.

    This often leads to iteration within designs and the production of cycles of feedback. Normally, in agile approach, the softwares are built way before stakeholder validation or before it's been put in front of the software user. This generally leads to loads of reworking cycles for the software development team.
  3. Unnecessary Cost and Rework:
    Unvalidated designs and bad architecture will eventually lead to large amounts of rework cycles which help inflate costs of production.

    If designers can't take a step back and critically assess the product, then they lose the ability to be able to develop libraries of design patterns that are extensible and that can be effectively used throughout the agile project.

Does Sprint Zero Help With Sprint Planning?

For any project to be executed effectively, pre-planning must be involved. The project preparations that are standard for most software developers include gathering the right equipment and people required in order to complete the job. However, these don't characterise a Sprint Zero process.

Sprint Zero, unlike pre-planning, is not a requirement for agile projects. Quick and efficient Sprint teams may not have any use for Sprint Zero procedures.

However, for those organisations that may never have used Scrum before, if you want your regular operational business culture to be ingrained with principles used in agile software development then you will have to start with the concept of Sprint Zero as your tipping off point.

Final Words on Sprint Zero

There are many alternatives to Sprint Zero in agile, however not many are as effective than this process can be when properly executed.

Before businesses and organisations start using Sprint zero they will first need to put in place organisation level processes with the main goals and objectives of sharing as well as crafting a vision, Scrum Team familiarisation and formation, initial product backlog creation, Definition of Ready (DoR) initial version, and Definition of Done (DoD).

An organization that intends to be successful with sprint in agile must fully understand all these processes mentioned above.

Before you go, lets look at another related topic...

What is an iteration backlog in agile?

What is an  iteration backlog in agile?

What is a an iteration backlog? In basic terms, it is smaller portion of the product backlog, it is a collection of activities that are expected to be completed in the next iteration. Ever since its incorporation into many companies, Agile has seen a huge cultural shift with support forums sprouting. It’s a methodology unlike no other, that mainly focuses on splitting of a workforce into several blocks for a more flexible output.

These building blocks, known as Iterations are fixated on a specific time frame for optimum productivity depending on the context of the business. Occasionally, a team may fail to deliver forcing the agenda to be carried forward and hence constituting an Iteration backlog. Here is a more detailed look onto Agile and its Iterations.

What are Iteration goals?

Iteration goals form the core of a business mission statement. In simple terms, a team is tasked to accomplish a set of targets within a specified duration of time. 

These goals may sometimes be demanding and even include backlogs that require prompt completion. Achieving these goals comes directly from the self-driven and organized set of Agile teams.

The drafted set of goals to be accomplished is both beneficial to the Project Management as well as the Agile Release-Train (ART). These constitute a series of teams that deliver solutions to benefit the end user.

Its beneficial to the team in that it will provide a context to be familiarized with, paving way to understanding objectives and cross-referencing with other teams if need be. Furthermore, it directly links the teams with the stakeholders allowing for managing dependencies and approved custom improvements during a program’s execution or update.

In as much as the self-organized teams are responsible for most of the work, Management is still mandated to oversee the course plan. As such, the management will be held accountable the teams value delivery outcomes.

Is Iteration Planning another word for Iteration Backlog?

Iteration Planning is a strategized gathering of the responsible teams to determine ways on how deliver the iteration goals as well as any backlogs that may be due. It is purely based on the team’s capacity as well as the Iteration’s complexity.

Its general purpose is to serve as determined estimation of the Iteration goals. It is much broader and focuses on the past backlogs as well as the upcoming issues. As such, it is a totally different entity.

As part of the management, you are not allowed to interfere with the team’s planning. The scope of the entire operation belongs to the capable team of individuals.

As a matter of fact, the members allowed into the meeting constitute:

  1. The capable team of developers
  2. The scum master whose basic objective is to spearhead the meeting.
  3. The owner of the product under development as well as any other important stakeholder

What is an Iteration Planning Meeting?

This refers to an organized preliminary gathering prior to the Iteration meeting. It is a very crucial gathering as the acceptance criteria and methods of delivery would be discussed.

Before conducting this meeting, you as the product owner are required to ensure the backlog has been assigned a story value. High-story values will be given first priority.

The stories may then be broken down into tasks which are assigned to the most capable members of the team. Sometimes, members may find themselves overtasked while others completely idle.

As such, a further review is recommended to evenly distribute the work. The iteration backlog may be too complex to be successfully delivered in one sitting. It is therefore recommended to solve backlogs by analysis of their story value instead of distributing it among the members.

As a reminder, the split backlog will have to be re assembled and hence it’s advisable to allocate a time frame to achieve this. Here is detailed approach on how to split a complex story value.

What is the goal of this meeting?

While the meeting is geared towards achieving the Iteration goals, you may want to understand its importance and of its other vision and missions. The goals of this meeting are purely specified in the meeting’s agenda and may include:

Complete scrutiny of the available Agenda Released Train tasked with completion of the backlogs and iteration goals.

Drawing out a rough estimate of the time required to analyze each story value and dig deeper into the seeded acceptance criteria.

Reiteration of the products’ vision and roadmap through reminding the members of anything in the foreseeable future.

Addressing new issues and concerns that may influence their overall productivity. These may include timeboxes and working hours required to complete a project.

Record Keeping – This requires precision and concentration on key topics such as the Iteration name, scope and theme of operation.

The stake holders in complete collaboration with the product owner will finally agree on whether to commit to these terms and estimates depending on the team’s capacity. As such budgets get drawn out and the work begins.

What is a “User Story” in Agile?

A user story is an Agile based feature that is able to adapt and create an outlook according to the requirements of the end-user. In simpler terms, it describes the user’s objectives, when he wants to do them and the reasons behind it. 

A good example would be:

  • As a user, I can file a list of orders into related subfolders.
  • As an Administrator, I can choose to authorize transmissions based on customer privileges and modify them if need be.

They are usually short and very descriptive of the task at hand. Preciseness is a valuable key feature in making a user story and it’s usually written from the perspective of the person intending to accomplish something.

They are often written throughout the agile project and added to the product backlog at any time to fit into an Iteration.

Conclusion - Iteration Backlog

Iteration techniques are crucial to the overall success of a business. The Agile software development tool has enabled smoother and more flexible facilitation of story values.

If you really want to get a return value for your money’s worth, it is important to purely base your investment by adhering to the Agile features. Iteration Backlogs can pose a huge threat if not properly addressed. A more capable team should be tasked with simpler tasks to ensure less backlogs.

How Do You Split User Stories in Agile Scrum like a Ninja?

Intro - How to Split User Stories

In the last 16 years, the Agile Scrum methodology has established itself as the top gun in the software development industry. About 71% companies today rely on Agile instead of the older techniques to get things done.

With its streamlined & meticulous processes and emphasis on modularization (User Stories), it has made the software development a more organized task.

Each User Story consists of a feature or functionality that the development team works to implement, in order to address a need of the client.
Let’s look at a few questions that most people are curious about when it comes to splitting the user stories:

What is splitting User stories in Agile Scrum?

Splitting of stories is very much like breaking down a big task into several small tasks. One big story is broken down into several smaller child stories that each play a role in the overall development.

Splitting should be done with the intent of delivering value to the client & making the development process relatively easier.

This is best achieved by writing child stories which target a capability of a feature. A feature is in itself a working unit that can function on its own, and as part of the bigger product. This translates to real and tangible progress for the product and the team. It also means that the team can quickly develop and test, and get feedback on it from the client.

From the development team’s perspective, the thumb rule is to split stories in a way that every sprint has a piece of feature/functionality that can be developed and tested properly.

2. What is Horizontal Splitting?

This approach involves splitting the story in terms of architectural layers. This implies that the entire story would be split on basis of work belonging to different teams: D.B, Front-end/U.I, Back-end, Security, etc.

This kind of splitting results in a situation where the customer can’t have anything useful or worthwhile to go with until everyone working on the different layers finish their respective share of work.

Development involves coordination of different teams (and people) handling different architectural layers. This approach jeopardizes the value& the process, if one team delivers their share of work, but the other doesn’t.

A working feature or functionality requires all layers to be working in tandem. If development is done layer by layer, there is an increase in the overall complexity. Unless one layer is ready, integrated and working fine with the other layer, testers can’t really test anything, thereby creating latency.

What is Vertical Splitting?

This approach to splitting revolves around splitting the entire story into several doable features or functionalities.This results in child-stories which when implemented, work to deliver some tangible result that’s valuable to the client.

A sprint’s worth of work creates substantial value to the client and helps the team in form of feedback that they can use to improve the functionality.

This is argued to be the best way to move ahead, since it implies that with time, the development team is creating usable functionalities or features. These work independently to get something done, and eventually integrate into the system to work with other such functionalities.

This improves the cohesiveness between different members of the development team, because they are all working on things that together contribute to the output. Also, it’s easier for them to coordinate in terms of how their respective share of work integrate.

What is splitting by business rules?

This approaches the splitting exercise based on the business motives/results that a client wants to achieve.

It works as a function of how much time it would take to get something done, and how important it is to the business of the client to get it done. This helps in deciding what’s the most important & urgent requirement, and what can be handled later.

Example: A web-store owner who ships cutlery will have different business rules needed to be implemented, such as:

  1. Customers should be able to pay through different payment options: Credit card, E-wallets, etc.
  2. Every order should automatically create a dossier with shipping information of the customer that can just be printed and attached to the parcel.

Out of these, the more vital need of the business is to be able to accept most payment methods. This ensures that customers wouldn’t be deterred from making a purchase just because their payment method isn’t listed. 
Meanwhile, the slip of the shipping details can easily be created manually.

What is splitting by data Types?

The parameters being accepted and the data types being returned drive the splitting process in this case. Depending on the priority of the data types and parameters that are being handled by the system, the priority of the child-stories is decided.

Thus priority is decided by evaluating which datatype is the most value-deriving in nature and hence most important to the client. 

A story that does similar operation using different data types can be divided into child-stories that individually address each datatype. This way, features can be built-up incrementally to work with more and more kinds of data.

A highly-preferred approach in this splitting strategy is to first integrate data types that are the easiest to process and are used most often, and then with time, build out to include the more complex ones.

Conclusion - Splitting User Stories

We’ve discussed few of the most important & widely used splitting techniques in the industry. You have been presented with some different techniques to make this happen.

It now comes down to you, to decide which method is best for you. Before you go, lets tackle another related topic that has many Agile fans attentions:

Agile User Stories vs Use Cases: Which one is Better?

Agile User Stories vs Use Cases: Which one is Better?

So, Agile User stories vs Use Cases: Which one is better?

Before we answer this, we'll discuss and explain a little bit more about what these approaches entail as well as the difference between the two. First and foremost, User stories are not the same as Use cases

User stories and User cases are not interchangeable. Both have their identified users and both have their own described goals, however, they serve very different purposes.

A User Story largely dwells on the results and benefits of the certain thing you're describing while Use cases are usually more granular and are centered on describing how the entire system will act. 

User stories usually start off pretty similar to Use cases in the sense that they are goal oriented, each has its way of describing how the system is to be used, designed with the user's perspective in mind and uses the businesses natural language.

User Stories In Agile

A User story is basically a small note that records what a user needs or does while they are at work. Each User story usually contains a written short description derived from the user's point of view in their natural language.

The main focus of a User story is to concentrate on the user's needs and not the expected results of the system.

It runs on a 3C's concept. The 3C's is a reference to the three vital aspects of what make up a good User story. These days when people are talking about User stories they're basically referring to a User Story that is made up of these 3 critical components mentioned below.

  • Card: User Stories are usually written as cards. Each card consists of a short sentence that has just enough content to remind all concerned what the stories are all about.
  • Conversation: Continuous conversations between development team members and customers throughout the whole agile software project are how requirements are found and then refined. Important decisions and ideas are usually recorded and discovered during stakeholder meetings.
  • Confirmation: This is the User stories' acceptance criteria. During the requirements discussion, the customers confirm to the analyst under what circumstances and conditions the software would be rejected or accepted.

What is a Use Case

Ivar Jacobson introduced Use Cases more than twenty years ago. Their main goal is to capture the point of view of the user while describing the system's functional requirements. 

This basically means that it describes all the ways the end user wants to use the system. Use cases capture and record all the ways the system and user can interact in order for them to achieve their goals as well as capturing all the variables that could go wrong.

There are various model elements that make up a Use case model system. The most important of them being the Actor, the Use case, and the relationship had between the two.

Use cases normally have detailed specifications. A specification in Use case is a textual description of the systems' functionality. It records Actor-System interaction. This means that it records system responses to user interactions.

The Acceptance Criteria In User Stories

A User story isn't all just about a single sentence affair. An Acceptance Criteria is also drafted by the product owner with the objective of defining User story boundaries as well as the confirmation of when a successful story has been completed and is working as it was intended to. 

Let's take this as your user story example: "As an attendee to the conference, I want to be allowed to register online, so that I can cut down on paperwork and register quickly ". The Acceptance Criteria could probably include:-

  • Registration databases have stored the information found on the form
  • Mandatory fields must be completed before a user can submit their form
  • Spam protection is working
  • Credit card payments can be made
  • Users receiving acknowledgment emails after successfully completing and submitting their forms.

Pros and Cons of User Stories

The Pros: Future of CIO state that a User story is an informal process kick-started by a simple sentence. Those of you that have the desire to add small increments of value, sooner rather than later, in agile, will find user stories to be extremely helpful.

It's not mandatory that the Use story be simple. Using Use stories that operate at a high level will add a little more to your productive planning sessions as well as a different way of adding last-minute functions to your software project.

The Cons: One of the most obvious disadvantages when using User story in Agile is that they usually leave out a ton of details because they rely too much on the conversational method of relaying time and details of development. The documentation is normally not complete upfront which can prove to be very time consuming

Pros and Cons of Use Cases

The Pros: The Agile Machine believes that formalized concepts are slowly phasing out Use cases. Some of the concepts provided when using Use case in agile include; ability to break down problems into subdomains and identifying actors. 

In addition to all this, Boost notes, upfront research that is sometimes required in Use cases can prove to be very helpful to the entire project in general.

The Cons: The fact that Use cases provide such formalized outlines of the project means that they often don't offer much room for project additions and negotiations. This is one of their biggest disadvantages.

Conclusion - User Stories vs Use Cases

All in all, they are both quite impressive. Having knowledge of both these systems may prove invaluable. When you start getting the sense and begin to understand the difference between

Use cases and User stories, you will know what purpose each of them, individually, can serve on your agile project. If your the type that only works with User stories or the one that only uses Use cases, maybe when the next project comes along, after you have completed your planning and risk poker, you can use both of them and see how that works for you.

The better one really depends on what you're working on as well as what you're really planning on achieving.

Best 4 agile Testing Certifications to Slap Your Competition

Best 4 Agile Certifications - Intro

In the agile domain, gaining credentials couldn't have been made easier recently. Why? you ask. Well, there's a large pool of certifications one can choose from in the market at the moment. 

It's even gotten to the point where it can get a bit confusing. Which bring us to the following point, we know when one has to invest time and money on something, anything for that matter, that individual will probably put in a lot of research before he dives into it.

It's no different with certifications and this is why we're here. We want to make things a little easier for you. Agile has basically revolutionised the whole face of project management and software development. This section of the article is mainly about 4 of the best agile testing certifications. below is a list of the certifications you should concentrate on.

01. ISTQB Agile Tester Foundation Level Extension

This is a new certification that has been introduced by the ISTQB. Software testing and development has taken a completely new approach in agile projects as compared to your typically regular software projects. Agile project testers need to now have sufficient understanding of Agile software development processes, testing methodologies and the techniques and tools used in the projects that involve Agile.

Before your eligible to take this exam you must have already acquired ISTQB Foundation Level Certification. The certification exam structure is basically a set of forty multiple choice questions that need to be completed in one hour. For you to pass the exam you'll need to score a minimum of 65 percent.

At the moment, some countries may not have access to the certification, however, you're advised on checking the certification board found in your country.

Taking this certification course will provide you with thorough knowledge of Agile Methodology. Most industries today follow agile processes. Getting this certification will confirm your Agile procedural know how to potential employers in the industry.

02. Certified Agile Tester (CAT) by QA

The Certified Agile Tester course is prepared by the International Quality Software Institute (IQSI) in Germany. It's a five-day course. You train for four days and on the fifth day you take a practical and written exam. 

The ISQI prepares all the training material going to be used for the duration of the course. The course material that is given basically includes; a comprehensive Agile Methodology introduction, comparisons to the traditional methods and the relevance of Agile. It attempts to cover as much as it can in depth.

Its certification examination structure is based on a written and practical exam. In the practical exam, they make you the customer, the team, and the tester. You have to do Iteration planning, take builds, do the retrospective and testing as well as preparing session charts. Kind of what you do in SCRUM

What follows is a theory exam that's quite subjective and no, it's not multiple choice.

For all three assessments, the minimum passing grade is 65 percent. However, candidates are required to get at least 50 percent in all the three individual elements of the exam. Delegates with disabilities or one that doesn't speak English as their first language is usually awarded a fifteen-minute extension.

03. Fundamentals of Agile Certification by ICAgile

If organisations and teams want to be successful in Agile, their foundation and main focus should first be on "being agile". ICAgile's key fundamental learning objectives comprise of vital concepts such as value-driven development, adaptive planning, frequent feedback for continuous growth and team collaboration. 

It also covers Agile's history, the Agile principles, the Agile manifesto and several other of its widely used practices and frameworks. Candidates that take this course come out understanding the core concepts of what Agile is all about.

The broadcast target audience has its eyes on ICP. This is because ICP is not only foundational but is a gateway to many other ICAgile tracks as well. For those of you that may be new to Agile or you"re practitioners who recognise they need to both "do" and "be" agile, then this course is perfect. ICP courses usually include 2 full days of activities and instructions.

04. Certified Scrum Master by Scrum Alliance

Scrum is basically an empirical method management framework that uses frequent inspection junctures to implement changes based on feedback and experience. Scrum has been used and has proved successful since 1994. The dot-com boom that was known to be highly competitive was its stomping ground. Many companies that have experienced tremendous growth during this time such as Salesforce and Google, have still continued using Scrum.

It all revolves around simple process framework that empowers individuals to higher performances where management takes a more leadership based school of thought rather than a directive approach, supporting multi-disciplined teams that are small in nature and removing any obstacles that prevent them from achieving their goals.

When you successfully complete the two-day course you'll be eligible to take Scrum Alliance's CSM assessment. Once you successfully complete this test you become a Certified ScrumMaster by Scrum Alliance. This is accompanied by a Scrum Alliance 2 year membership. Real examples are used in the course to discuss approaches, options and implications a ScrumMaster needs to always have in mind when dealing with development team members, stakeholders and product owners that are not well versed with Scrum.

Conclusion - Best Agile Certifications

All in all, Agile practitioners look to have a bright future ahead. There is literally no better time than right now to get started with your journey into the Agile realm. All the critical certification options mentioned above can place you on the road to success along the Agile career path.

There's no doubt that there are numerous other certification courses other than the ones highlighted in this article, however, the ones mentioned above are some of the best money can buy, that are available on the market at the moment. However, it goes without saying that as a professional you'll still need to make a wise call and have a slight idea of what you're looking for. It generally all starts with you.

If you decide to focus on the ISQTB Agile Certification extension to start with, we have some further tips for you here:

Where to Unlock the best ISTQB Agile Tester Extension Certification Dumps?

Unlock the best ISTQB Agile Tester Extension Certification Dumps

Where to find these dumps

If you are looking for the best Agile exam dumps or mock exams, you can find some here:

Almost every decent software development company today follows the Agile methodology to get things done. While the weekly sprints impart all the practical knowledge, there’s still a growing emphasis on certifications to get the theory right. 

ISTQB provides the option for taking the widely accepted certification for Agile Testers. This certification is considered de facto in terms of knowledge & reliability and opens doors to go for more advanced levels of expertise in the domain.

However, most people may be left with a bad taste in the mouth, since there’s hardly any time left to study after an entire day of work in the office. For addressing the same, the concept of Agile Tester Extension-Certification Dumps was introduced.

The relevant material is available in the form of books authored by people who’ve been in the Testing industry for many years, and courses that cover the nuances of the topics concerning the Agile methodology.

Let’s look at a few basic questions that are frequently asked by people who are pursuing the certification:

What is the entry criteria for the Agile-Extension Course?

  1. The Agile Extension course requires a person to be certified in the Foundation level course by ISTQB.
  2. The Foundation level certification itself requires that a person should have at least 6 months of experience working as a professional tester.
  3. While there is no hard and fast criterion relevant to this, there are two camps of people who typically take the extension course:
    • People looking to learn about Agile from scratch:
      If you are starting out from scratch, the entire course proves a boot-camp, since you discover everything from the very beginning. These are people who have started out new in the industry, or a looking to add to their expertise.
    • People with prior experience with Agile:
      This provides leverage in making the best out of this course. This is because the practical implementation of Agile in your work methodology sets you up for a better understanding of how things are supposed to be done.

Are there any books that can help me prepare?

Yes, there are. A very comprehensive document prepared by ISTQB is where you can start your preparation from.

This is a pretty solid resource since it covers all the boundaries of Agile. Right from the basics of Agile testing – terminologies as well as explanation, their importance, it moves to skills, methods, and lists down tools which come handy in the process of Agile testing.

People who have cleared the exam have recommended books like:

  • Agile-Testing & More Agile-Testing by Janet Gregory and Lisa Crispin. The authors have substantial experience working in the testing domain and have provided insights that the textbook documents and syllabus may have missed.

If you are looking for alternate means of learning, there are online courses & videos which provide this knowledge, like this one:

Further, there are other books that are favoured greatly by users. They’ve been discussed below in detail.

Is the Agile Testing Foundations-Book by Rex Black & Gerry Coleman any Good?

By popular opinion, Yes. Most readers of the book have agreed that the book serves as a one-stop solution for anyone pursuing the Agile Tester-Extension Certification.

The book is neatly divided into sections that address all the concepts. Further, all the concepts are elucidated in a language that’s both easy to follow and effective.

Definitions and important concepts are highlighted, and this makes visiting specific parts according to the need of the hour a walk in the park.

The concept of Continuous evaluation and assessment is thoroughly practiced throughout the book, in form of sample questions at the end of each chapter. You get to pit your knowledge of concepts against the questions very often and this helps in tracking your progress.

Is the Sample Exam-Questions Agile-Book by Chhavi Raj-Dosaj any Good?

Chhavi Raj Dosaj is considered a reliable name in the world of literature concerning the Software Testing. His experience of over 17 years working with Fortune 500 has been consolidated into a single book. 

The book features questions that impart knowledge beyond the confines of the syllabus. This proves to be a boon for anyone who is looking not just to clear the exam, but also to extract maximum knowledge on the subject.

One of the highlights of the book is that each question is accompanied by the answers and the explanation behind the right answer and the wrong ones. Deviation of the interpretation of concepts from reality can prove fatal to your attempt at the certification exam. This approach taken by the author takes the guesswork and speculation out of the equation. Hence, you can understand the subtle details of concepts.

Can you take this ISTQB Agile-Testing Course Extension Online?

Yes, you can. ISTQB doesn’t directly provide these certifications. Instead, they’ve authorised training companies to provide these certification training and conduct the examinations.

You can take the certification training both in physical attendance and online, depending on the facility provided by the training company you choose to go with.

Every geographical location has certain companies that have been authorised to provide these certifications, and you can take the certification &examination with them.


In the pursuit of knowledge, we come across many such questions. Hence, we understand the importance of having the right and reliable advice on these matters. We hope that whenever you appear for the Agile Tester Extension Certification exam, you ace it.

However, it’s important to realise and understand that in the pursuit of betterment and progress, one shouldn’t be limited to books & syllabuses surrounding a certification. It’s important to look for forums where discussions related to Agile methodology’s implementation happen. That’s where you’ll find the most relevant and updated advice after you’ve exhausted the books.

As always, we’re open to discuss our points and answer any questions that you may have. If you got the answers you are looking for, and know someone who could use these answers – share this page with them! 

Skip to toolbar