What is scrum methodology?
Scrum methodology - what is it?
Perhaps you've heard the term scrum mentioned by your organization or perhaps you've heard it mentioned by your colleagues. You might even be job hunting and it has come up on the list of requirements. So what exactly is scrum methodology?
In simple terms, scrum methodology is a method of project management. It is typically used on development projects such as web developments and software applications.
Scrum is part of a family of methodologies called agile. So we'll start this article by first talking about what agile means and then look at how scrum fits in to this.
What is agile methodology?
Agile is the umbrella term for all techniques following the same specific approach to software development.
A quick history lesson: back in 2001, representatives from industries relating to software development met to discuss approaches and created the agile manifesto (referenced below). The agile manifesto agreed 4 principles on which to apply to software developments. These 4 principles are what separates agile from more traditional approaches to software development:
A link to the Agile Manifesto website
- Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. These are our values and principles.
The agile manifesto
The four principles of the Agile Manifesto
These are the four principles that were agreed upon for the Agile Manifesto. They perfectly summarize the key characteristics of an agile approach to development:
- Individuals and interactions instead of processes
- Working software instead of documentation
- Customer collaboration instead of contracts
- Responding to change instead of following plans
Where scrum fits in
If agile can be thought of as a defining principle for software development, scrum gives a specific framework for implementing it. It is not so much a step by step guide, but it gives techniques, terminology and roles that project managers can be trained in and apply to a project. There is even a certification in the methodology, and you can become a certified scrum master.
The basic principles of scrum
Many articles about scrum launch with a diagram of how it all works, all the terminology and the roles of each member of the team. I'm not going to do that. I'm going to start by explaining one of the core features of scrum, as I think this is a much better way of illustrating how scrum actually works on a day to day basis.
Scrum and the meaning of a sprint
I'm going to explain scrum by talking about one of the main features of scrum: a sprint. What comes to mind when you mention the word sprint? A fast dash to the finish line. Of course, that name is very deliberate. A sprint is a short, focused piece of work, with a clear goal in mind and undertaken with a bundle of energy.
A project is made up of multiple sprints. So following on from the running analogy, you can consider sprints in this way. You have a kilometer run to do. Rather than running the full thousand meters, you run it in 100 meter sprints. At each sprint, you stop, think about what you've achieved and look at whether you'll tackle the next 100 meters differently. This is a highly simplistic way of thinking about sprints on scrum projects, but it's a useful way to understand the terminology if you are not familiar with it.
On a scrum project, you start off with a broad overview of the work involved to reach your goal. You break this work down and identify some tasks you can group together into a package of work. This is what is known as a sprint. A sprint is a defined period of time - typically between 1 and 4 weeks, in which you achieve as much as you can on the project. This differs from traditional project management techniques which look at the full list of tasks to achieve the end goal and then work out how long that will take.
Defining what work is to be done
I mentioned that a sprint is made up of a defined time period. This is a distinct characteristic of scrum - setting a time period first and shaping the work to fit, whereas typical project management techniques will define the tasks first and shape the time period to fit.
This almost seems counter-intuitive to a seasoned project manager. However, this is a clever approach. What you are essentially doing is looking at how much you can achieve in a restricted period of time and the reasoning behind this is that you are more likely to achieve your goal.
Consider for a second this analogy. You have a date round for dinner at 8pm. You return home from work at 7.30pm. What are you going to cook? Well, you will come up with a recipe that you are confident can be cooked in that 30 minutes, and something you know will impress. Compare that with an alternative approach. You have a date coming round for dinner. They turn up at 6pm and you offer them a drink whilst you cook dinner. You really want to impress them, so you think about cooking a really fancy three course meal. How long should that take? Two hours according to the recipes. So you tell your date dinner will be ready at 8pm.
In the second example, you've put yourself in a really risky situation. Yes you have three hours, but you have three separate courses to cook, and they are all pretty complicated. What if one of them takes longer to prepare than you thought? Your poor date will be all on their own wondering when the food is arriving. However, if you know you only have 30 minutes, you have to be a bit more realistic about what you are going to do. You only commit to cooking what you know will be ready in 30 minutes.
Choosing work to go into a sprint
Ah, you're thinking. That example is all very well, but scenario B achieves a lot more. Three courses. And a fancy menu. Scenario A had an easier task so that's not a fair comparison.
However, that is precisely my point. A project isn't about achieving the most elaborate and impressive result. It is about reaching a goal. And by using scrum you are less likely to over-commit. Over-committing is what causes so many projects to fall into the disaster zone and also the thing that causes some projects to get such a bad reputation. Over-committing forces you to take on too many risks and exposes you to making too many bad decisions. By splitting the project into defined time periods and only analyzing what can get done during that time, you are more likely to achieve the desired result.
Making a sprint meaningful - the real skill of scrum
One of the smartest aspects of scrum, and with agile in general, is the defining principle that working software is valued over documentation. Small, basic, working software with limited functionality is valued over detailed, complex documentation of a full and comprehensive piece of software. What scrum does is apply this principle to sprints. Each sprint should have something tangible and working at the end. The rule of thumb is this: if the project were to be cancelled at the end of the sprint, there should still be something delivered that is working and that is of value.
This is the abiding rule for a scrum team when planning a sprint. Rather than looking at the entire project, they look at something far smaller that will get them a step closer to their final goal.
A snapshot of the scrum methodology
This touches the surface of scrum. There is much more to discuss and I will explore that in future articles. However, this should give you a decent overview of what scrum methodology actually is. Here is a recap of what I have discussed:
- Scrum methodology is part of the family of software methodologies called Agile
- Scrum methodology abides by the principles set out in the Agile Manifesto
- Scrum methodology is a technique and you can get trained and certified in it
- A scrum project is made up of small chunks of work called sprints
- Each sprint is a defined period of time, typically between 1 and 4 weeks
- Each sprint has a definite goal, and that should be something tangible
- If a project were to be cancelled at the end of a sprint, there would still be something of value to show for the project
Add your comments below. What questions do you have about scrum? Is there anything about the methodology that you find appealing? Is there any part of the methodology that you disagree with?