Agile Scrum is not a Methodology, but a Framework

Here we continue our series of publications on approaches to software development.
If you missed the beginning, start with our ultimate Agile guide. Once you’ve gained an understanding of this software development philosophy, come back for an in-depth look at one of its frameworks.
“Scrum is an agile framework for managing knowledge work, with an emphasis on software development”, as Wikipedia says. Early Wiki also said that Scrum is a methodology. But now we see that Scrum guys have changed it.
Imagine you need to build a house. It should have walls, windows, doors and a roof. You need a kitchen, a bedroom and a bathroom to feel comfortable.
However, nobody can tell you what colour to paint it or what brand of furniture to choose from. Similarly, Scrum is a framework – a set of recommendations.
It guides the development process by helping to:
What it does not provide is a list of To-Do instructions.
But it provides you with all the necessities to organise your project and give it a boost with your own tools and techniques, making for effective teamwork and a great end product.
Several popular frameworks exist within Agile: Kanban, Scrum, Extreme Programming (XP), etc. Let us see what makes Scrum different from other approaches to effective IT project management.
Scrum aims to instil certain values in teams: Courage, Focus,Commitment, Respect, Openness. This framework advocates the inculcating of personal responsibility is each developer and the encouragement of co-operation and a friendly working environment.
In our Agile guide, we gave a profound explanation of the three vital roles in Scrum: team, Product Owner (=Product manager) and Scrum Master.
Basically, the Product Owner (PO) and the Scrum master are managers.
The PO is a sculptor for the product, he (or she) presents the idea to the team, helps them set priorities and is responsible for the results.
The Scrum Master (SM) is an independent person who helps development teams to work effectively. They facilitate meetings and make sure that all Scrum procedures are being respected.
Sprint Planning meetings, Daily Stand-ups, Grooming, Sprint review and demo, Scrum Retrospective and others referred to as “events” are an indispensable part of Scrum. Some experts tend to believe that without daily meetings, the approach no longer qualifies as Scrum at all. Read more about the events here.
Planning Poker is one of Scrum’s rituals for organising collaboration on the project. It’s conducted during the Sprint Planning meeting. As you can see, Planning Poker is not mentioned in the Scrum Guide, but for many teams is a regular and required ritual. This fact again confirms that Scum is a framework, offering teams the ability to find and use the most effective tools to organise their work.
To organise Scrum Poker, one needs a list of features to discuss, a special set of measures for estimation (the most popular are the Fibonacci numbers: 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144,..) and a Scrum master to guide the process. Each of the stories is read aloud and assessed simultaneously by each member of the team (except for the Scrum master and PO).
The highest and lowest scores must then be explained (proved) by their owners. After several sets, all the team members agree on the estimation and continue with the next feature. Follow this link to discover all the mechanics of this game procedure.
As a result, group decisions are done quickly.
Artefacts in Scrum can be understood as a result of the teamwork that helps to complete the project successfully. It’s up to each team whether to use all of them or to implement some/mix with other framework elements.
These are the artefacts and the tools used to acquire them according to the framework:
This artefact represents a long-term goal of the project/product. It should be short, clear and memorable so that every member of the team knows it by heart.
The statement can contain all or some of this information:
For example, the product vision for our StarBuffet project looked like this:
“For an Australian self-catering service who wish to increase the efficiency and transparency of their workflow, the StarBuffet app will decrease labour costs and increase profit by controlling at-station food availability automatically. Unlike its competitors, this app also manages order completion timing and sends notifications to customers when food is ready”.
A sprint goal is an objective to be met within the Sprint. It includes the implementation of Sprint Backlog items and is the result of PO-team negotiations.
Product Backlog is a dynamic list of all the required features and functions compound by the product owner. It sets the priorities for the team and points out what items are still undone.
A Sprint Backlog comprises Product Backlog items selected for the Sprint and the plan for Increment delivery. It shows how likely the successful realisation of the Sprint Goals.
Every Product Backlog item has acceptance criteria. They define what allows the work to be declared done.
For example, the team can set up a specific DoD for User Stories (to understand that User Story was completed), DoD for Sprint to know when Increment ready to ship, and/or a DoD for the overall product to be sure it's ready for production release.
Burndown charts are graphs that give an overview of project progress and predict will Sprint goals be achieved or not. As tasks are completed, the graphs “burn down” to zero.
An increment describes how many Product Backlog items have been completed during the current and previous sprints.
When an increment is ready to ship it must be marked as “Done”. For this to happen it should meet these two criteria:
User stories are short descriptions of certain features from the perspective of a user. Find out here how to write great user stories and how the teams use it to develop products that customers really want.
Scrum appeared at the same time the Agile manifesto was written – in 2001.
In 2002, Ken Schwaber founded The Scrum Alliance, offering certified ScrumMaster programs. Having completed them, anyone could become a Scrum master with the job of introducing the Scrum framework to IT companies and helping them to maintain it.
The first guide on Scrum was published in 2010. Ever since Scrum has been gaining widespread popularity not only in IT but also in business management.
Scrum and Agile relate as a philosophy and a practical means of bringing it to life – with roles, instruments, artefacts and guidelines.
Scrum is the most popular Agile framework in IT project management today. There are reasons for this:
A people-orientated development process with a focus on quick delivery of valuable business results organised in short iterations does not permit the wasting of time on remaking the whole project after release.
Only a limited number of features are worked on at any given time. This allows teams to focus more on quality and deliver outstanding products.
In Agile, the development process is much more transparent for clients thanks to regular demos and intermediate requirements correction. This guarantees that the final product will be what the client expected.
Stay tuned for more posts about Agile frameworks, the next one is already in the queue. In the meantime, check out the other posts on our blog and a couple of books, which we recommend:
- Learning Agile: Understanding Scrum, XP, Lean, and Kanban 1st Edition by Andrew Stellman;
- Agile Estimating and Planning by Mike Cohn.