Many sources say Scrum has a build phase and test phase, but I'm wondering if these are separated stages since continuous integration essentially combines build and test into a loop.

  • 4
    Can you give a link to one (or more) of those sources? I have the feeling that someone has misunderstood something. – Bart van Ingen Schenau May 11 at 7:23

The Scrum Guide says nothing about build phases and test phases, however it does say:

delivering a potentially releasable Increment of "Done" product at the end of each Sprint

Essentially that means having separate build and test phases is not Scrum.


Scrum intentionally does not say how to do the work. It just says that you should have a potentially shippable product increment at the end of the sprint. From a software standpoint, it would be hard to argue that a software product is potentially skippable without being tested and built.

The idea of phases as part of product development is not expressly forbidden in Scrum, but it is problematic. Phases usually lead to both wait states and batching, which become difficult to reconcile with the short sprints. To your question, practices like continuous integration that largely eliminate the phase concept in favor of rapid repeatable micro-actions are usually adopted by more practiced scrum teams working in software development.

Now, despite the Scrum guide only being 16 pages, there are hundreds of thousands of pages of books and blogs trying to implement it. This is very difficult when companies with monolithic build processes and tightly coupled application architectures try to create a potentially skippable increment in a few weeks. This has led to a lot of writing about coping and bridging strategies that have, unfortunately, become so common that they are starting to be seen as norms or best practices.


Scrum doesnt have a test phase, but a sprint can have testing involved in within the sprint time box, but generally people think that they can do testing work at the end of the sprint, but in actual one should continue the testing work in parallel with the development of code.


Scrum says that each sprint provides a potentially shippable product increment at the end of the sprint. So to be able to provide a shippable product, the sprint involves develop and test togeather. i.e in-sprint testing. Now as organization have started scaling,the product required by the team are also grown. So this will involve multiple teams, applications working together. Now at this stage many organization need a seperate team to verify the interation/Acceptance tests. This separate team need to focus on continuous integration and deployment, and continuous regression.



Scrum allows you to build and test any way you like within the constraints of the framework. Agile best practices favor active collaboration over a phased approach.

Scrum Isn't Prescriptive About How You Build Products

Scrum is a framework, and the official Scrum Guide limits its guidance about how a product is built and tested to:

  1. Requiring a central coherence to each Sprint.
  2. Defining the expected output of each Sprint as a potentially-shippable increment.
  3. Setting the expectation that there will be a Definition of Done that includes testing and integration work.

    Each Increment is additive to all prior Increments and thoroughly tested, ensuring that all Increments work together.

Within the boundaries of the framework, you are free to employ whatever workflows, practices, and techniques you like so long as they don't violate the immutable aspects of the framework.

Agile Build and Test Cycles

Scrum doesn't define a build-test cycle as such, but it does define an inspect-and-adapt cycle (implemented primarily through Scrum Events). However, most agile frameworks (including Scrum) treat both development and testing as continuous cycles rather than distinct phases. While you can separate development from testing, this introduces unnecessary friction into the process. The application of agile principles generally requires that the development process (which certainly includes building and testing the product) be viewed more holistically. Specific practices like the use of test-driven development (TDD) or the INVEST mnemonic are used to implement this intertwined and cyclical approach.

While the steps in test-driven development (e.g. "red, green, refactor") may make it seem like testing and development are separate activities, when done properly they are so tightly interwoven into the process as to form a continuous cycle. Likewise, when done properly, continuous integration and continuous testing practices create a continuous feedback loop.

The notion of linear phases, and specifically phase gates, is generally orthogonal to agile practice. Effective agility requires a reduction in upfront planning, hand-offs, and both parallel and sequential development practices. To be fully agile, the framework and the techniques employed within it need to embrace active collaboration throughout all aspects of the development process.


By test, if you mean testing a Beta version of the product, then that should be planned separately. A sprint, however, should include unit tests (if not regression) before considering a task done.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.