How many phases are there in Scrum?
A lot of people ask about phases in Scrum – such as when do they happen, how many are there, and so on. Many of these questions come from a misunderstanding about Scrum and its opposition to a phased-based approach to software development. This article will discuss the phased-based approach in the context of Scrum, and answer the question of how many phases there are in Scrum. The answer may surprise you!
Overview of Scrum and cadences
Scrum is a framework for software development, and is used widely around the world. It is one of the most if not the most popular frameworks for putting the ideas of the Agile Manifesto into practice. It is based around a small cross functional team (consisting of a Scrum Master, Product Owner, and one or more developers) who work in short sprints, creating a product increment each sprint. They continuously pull work from a Product Backlog.
While it started off in a software development context, Scrum has grown in popularity and is used in all sorts of environments and situations around the world.
Scrum is best suited for product development and collaboration, where a team is building a new product under conditions of uncertainty. The key point for it is that it operates in sprints, which are short timeboxed periods of the same duration.
Phases and phase gates
What are phases?
Scrum was created largely in opposition to the traditional project management approach to software delivery. In this model, a software project was broken down into separate phases, and each phase had to be completed before the next one could begin.
A typical set of phases would be Analysis, Design, Build, Test, Release.
All of the work and deliverables for a phase would need to be finished and signed off before the next phase can begin.
Where phases come from
This phase model comes from the traditional project management approach, based on ideas in the PMBOK (Project Management Book of Knowledge). It was also described by computer scientist Winston Royce in a 1970 article. What many people don’t realise though, is that in the article, after describing the Waterfall model, he actually recommended that it not be used!
Phases were more useful in a construction based context, where all the details were known up-front, were difficult to change, and risk and uncertainty had to be extremely strictly controlled. If you are building a bridge or skyscraper, you know exactly what you want at the end. You know exactly how all the parts are supposed to work together. It is almost impossible to change the design or function of the building halfway through.
Software development is a completely different set of circumstances, however. Each piece of software is by definition being built for the very first time. Otherwise, we would just be copying it! It makes no sense to build exactly the same piece of software that has already been built before. There is therefore inherent risk and uncertainty about the product.
We are also much more able to change the design or function of the software at any point in time, even after much of it has been built.
So since the context is so different, phases might not be the right approach for a software development context.
How many phases are there in Scrum?
As you may have guessed by now, there are zero phases in Scrum! The Scrum framework is inspired by the Agile Manifesto, and rejects the very concept of phases and stage-gates.
Those are concepts from a very different approach, that is fundamentally opposed to the ideas of agile.
Don’t have phases across sprints
If you are doing Scrum, do not set up phases across sprints. Don’t have an analysis sprint, a design sprint, a build sprint (or sprints), and a testing sprint.
That is just doing Waterfall! It is defeating the entire point of agile and Scrum. Instead, we want to be doing some analysis, design, build and testing (and/or whatever other activities are required) in each and every sprint.
Leaving all the testing to the end is an especially bad practice. That moves all of the risk into a big blob right at the end of a project – which is not where you want it!
Doing all of your analysis and requirements at the beginning is a terrible idea too, since it leaves no room to change these as you go. Which, again, is the whole point of Scrum!
Don’t have phases within sprints either
Another bad and more subtle practice is what people call “mini-waterfall”. This is where you are doing those activities within a sprint, but the sprint itself is broken up into phases. You start off doing some requirements, then quickly try and build a few things, then quickly try and test them right at the end.
The team instead should be continually swarming and moving between work and tasks. Ideally, the smallest piece of work should be completed (all the way to Done) as quickly as possible in the sprint. Then the next smallest item. This maximises work completed / flow and reduces cycle time.
How and why to avoid phases in Scrum
Why we don’t want phases in Scrum
We don’t want phases because they separate tasks that should be done together, they violate the “whole team approach”, they create blockers and handovers, and reduce flow. They also remove the ability to adapt and change. Phases are OK in some contexts but are terrible for software development.
How to avoid phases in Scrum
It is pretty simple – don’t use them! Each sprint should have a bunch of all the activities required to get work done (analysis, development, testing, etc.), done in parallel. No work should need to be “signed off”. If it meets the Definition of Done, it is Done. That’s what the definition of done is for!
Conclusion
I hope you can see that there are definitely no phases in Scrum
Do you have some experience here or do you have an alternative view? If you have questions or thoughts, leave them in the comments!
