What is the Scrum Framework? Agile is the use of an Adaptive lifecycle. This is a high-level concept, and we need a practical approach to run projects based on this concept. That’s where the methodologies (and frameworks) come into play.
There are a few Agile methods/frameworks, but there’s just one that is widely known and used: Scrum. Scrum has dominated the market so much that people have a hard time talking about Agile without making it specific to Scrum.
The core framework of Scrum is described in the Scrum Guide (ScrumGuides.org), which is a short explanation of the framework, but not as easy to read as this book 😉
It’s a great sin to call Scrum a methodology; it’s a framework. It’s difficult to explain the exact difference between the two because there’s no clear distinction. But the overall idea is that a methodology is a more sophisticated “thing” that supports complicated situations, and you need to simplify it if you want to use it for simpler projects, while a framework is the bare minimum needed in all projects, and you need to add to it to support more complicated projects.
However, between you and me, I believe they don’t like the word methodology because they find it to be something “traditional” that belongs to the “waterfall” systems. But, maybe that’s just me.
We’re going to discuss many details about Scrum, but you need to have an overall understanding first. So, I’m going to explain the whole framework as simply as possible here.
Each Scrum project is done in a number of Sprints. “Sprint” is the Scrum term for “iteration”. We use a Product Backlog to define the remaining scope of the product. We pick a number of items from the top of the Product Backlog and add them to the Sprint Backlog, which is our plan for the upcoming Sprint. We run Sprints as many times as required until:
- the project is finished because:
- all the items in the Product Backlog are done;
- the customer has realized that the latest increment is enough, and there is no justification to spend more time and money adding more features; or
- the project is terminated for some reason (e.g. it is not justifiable anymore).
The next figure shows an overview of the framework:
The last image above shows what happens inside Sprint #6, which is the exact same routine for all Sprints. The events inside the Sprint are all timeboxed, and are as follows:
- Sprint Planning: a short timebox for selecting the user stories from the top of the Product Backlog and creating the Sprint Backlog.
- Daily Scrum: a 15-minute timebox to collaborate and coordinate on a daily basis.
- Sprint Review: for demonstrating the increment and communicating progress to the customer and receiving feedback.
- Sprint Retrospective: for reviewing the way of working and planning for improvements in the next Sprint.
There are three roles in Scrum:
- Product Owner – this person is responsible for maximizing the value of the product. It’s done by creating and maintaining the Product Backlog; constant communications with the customer, end-users, and developers; and so on.
- Scrum Master – this person ensures that the Scrum framework is followed entirely and correctly, which requires coaching, training, and problem solving.
- Development Team – a set of technical, yet self-organized and cross-functional experts who develop the solution.
Note: “programmers” are usually called “developers”. In Agile literature, a “developer” is anyone who contributes to the production of the final solution. It can refer to analysts, solution designers, UI designers, programmers, testers, etc.
OK, that was the quick overview of the framework. Now let’s go through some details.
There are three roles in a Scrum project; no less, and no more. Scrum does not allow any other roles to be defined because it is harmful to the unity of the team and it is not compatible with the philosophy of Scrum.
A Scrum Team consists of the following three roles:
The term “Scrum Team” refers to all the project team members: everyone internal to the project. Scrum Team members usually have only one of the three standard roles of Scrum: Product Owner, Scrum Master, or Development Team member. It is possible for a single person to be assigned to more than one of the roles, but it is not recommended.
Note: “Scrum Team” and “Development Team” are two different things.
Other persons can be involved in the project, but they are not considered internal to the project, and Scrum does not have much to say about them. They should have a certain set of behaviors, though, to make it possible for a Scrum project to succeed.
The customer (either internal or external) should understand and adopt the Scrum framework, too, as the relationship between the customer and the Scrum Team and the way we deliver the project completely changes when we switch to the Scrum framework.
The Scrum Team has two essential characteristics:
- Self-organized: The Scrum Team manages its own efforts rather than being managed or directed by others. In some other approaches, management efforts are separated and centralized; a subset of the project team is responsible for project management, and others are only responsible for specialist activities. However, management and specialist efforts are not separated in Scrum.
- Cross-functional: The Scrum Team –as a whole– has all the expertise and competency needed to get the job done without any help from outside the team.
Next, we’ll take a look at each role
Want to know more, get the Agile Scrum Handbook or read more in one of the other Agile Scrum Hanbook blogs.
Nader K. Rad
Project Management Author, Speaker, and Adviser
Relavant links Scrum Framework
- 9789401802796 – hardcopy
- 9789401802789 – eBook
- Author: Nader K.Rad & Frank Turley