What is Scrum?
Scrum is essentially a method for structuring the way a team communicates with each other while they incrementally build a product. It was developed by Jeff Sutherland and Ken Schwaber in the early 1990s as a framework for software development teams to simplify the process of building complex systems. Its influence has since spread beyond software development, and it is now used by teams across a broad range of industries.
A good way to learn about Scrum is by reading The Scrum Guide, and Jeff Sutherland’s excellent book Scrum: The Art of Doing Twice the Work in Half the Time.
However, when learning about Scrum and putting it into action with a team, it can be easy to focus on the method and forget about the agile principles behind it. This article tries to cut through some of the jargon surrounding Scrum and explain it in terms that give a little more context.
The Team
A scrum team is usually made up of 3-10 people, the idea being that smaller teams communicate better and are more productive. Within that team, there is no hierarchy, just three defined roles:
1 x Product Owner
This person helps the team to understand the problems the product needs to solve, ensures they stay focussed on delivering value, and regularly communicates with stakeholders and users.1 x Scrum Master
This person helps the team and the wider organisation to understand scrum theory and scrum practice, and helps the team to stay focussed by removing anything that gets in the way of progress (referred to as impediments).1 - 8 x Developers
The term Developers doesn’t mean everyone is a software developer, it’s a general term for the people who build the product. Although people within the team will probably have different areas of expertise (e.g. software developer, QA tester, UX designer etc) everyone should be willing to get involved in any type of work to help the team meet its goals.
The scrum team should have all the skills needed to do the work (cross-functional), and should internally decide who does what, when, and how (self-managing).
Goals & BAcklogs
A motivated, self-managing team needs to have well-defined objectives and a clear understanding of the ‘why’ behind what they are being asked to build. Scrum helps with this by requiring the team to have the following in place:
Product Goal: a long-term objective for the Scrum Team. It should offer a high-level vision of a future state of the product, giving context as to why the product needs to be built.
Product Backlog: a list of what is needed to build/improve the product. Individual items in the backlog are referred to as Product Backlog Items (PBIs)
Both of these are owned and managed by the Product Owner and are subject to constant review and refinement in collaboration with the development team and stakeholders.
The Scrum Guide does not give any explicit guidance as to how the Product Goal or Backlog should be communicated or maintained, this should be at the discretion and best judgement of the team.
TIP: Think about each Product Backlog Item as a small experiment. Each step you take towards achieving the Product Goal should be something that can be tested in the real world to see if you’re headed in the right direction.
Definition of Done
Deciding when something is truly done can be subject to interpretation. Therefore, Scrum requires that the team agrees on a Definition of Done, so that there is a clear set of quality measures a Product Backlog Item must meet for it to be classed as releasable or suitable for use in the real world.
The Rhythm of Scrum
Scrum is designed to allow the team to work to a regular, predictable rhythm, constantly moving towards achieving the Product Goal. A fixed time period is decided on (this often tends to be two weeks but it could be anything from a day to a month) which forms the basis for a repeating pattern of planning, building, reviewing and releasing working increments of the product. With each increment, the team gets closer to achieving the Product Goal.
Sprints run one after the other - there is no gap between them, and they don’t overlap.
What Happens in a Sprint (Scrum Events)
Sprint Planning
Duration: Max. 8 hrs for a 1 month sprint, should be shorter for shorter sprints.
The sprint begins when the team get together to discuss a small goal they will work towards that will take them a step closer to reaching the Product Goal. This goal, known as the Sprint Goal, should be a single objective or outcome that gives context to the sprint, but doesn’t define the exact work needed to achieve it. The team agree on the goal, then discuss what work they will do from the Product Backlog to achieve it, and plan how they will do that work in the time available.Daily SCrum
Duration: Max. 15 mins
The team gathers at the same time every working day of the sprint to discuss how they are progressing towards the Sprint Goal, and to come up with a plan for the next 24 hours to make more progress towards the goal. It’s important to remember that this should not be the only discussion that happens throughout the day between teammates - you should be working collaboratively and talking as much as possible - but it’s a great way to start the day!Sprint REview
Duration: Max. 4 hrs for a 1 month sprint, should be shorter for shorter sprints.
At the end of the sprint, the team gets together with any relevant stakeholders, takes an in-depth look at what has been produced during the sprint and discusses whether or not the Sprint Goal was met. This is also a good opportunity to discuss user feedback, as well as any recent events or changes which might have implications for the future of the product. All attendees collaborate on what to do next based on the information gained during this meeting, and new items or amendments may be added to the Product Backlog.Sprint REtrospective
Duration: Max. 3 hrs for a 1 month sprint, should be shorter for shorter sprints.
The team get together after the Sprint Review to discuss how they worked together as a team and decide on any changes that could be made to improve their effectiveness.
Scrum Theory & Values
Scrum is designed to provide a structure for the relationships and interactions of teams members without prescribing how they should do the work. It puts heavy emphasis the following concepts:
Empiricism - knowledge comes from experience, so we should make decisions based on what we can observe.
Lean thinking - we should remove things that waste time and focus on essentials.
Transparency - everyone working on a product, and the people who will be benefitting from it (stakeholders and users) should have good visibility of the product at all stages of its development and the process being used to build it.
Inspection - the Product and the Product Backlog should be viewed and discussed at regular intervals.
Adaption - if the regular inspection of the product shows that it is headed in the wrong direction, changes should be made to either product or processes.
Because Scrum is designed to encourage clear lines of communication, it depends on people being ready to work collaboratively and to speak openly and honestly with each other. To promote this, the Scrum Guide describes five values that Scrum Team members should follow:
Commitment to achieving goals.
Focus on the work needed to achieve goals without distraction.
Openness about the work and its challenges.
Respect for each other.
Courage to do the right thing and work on tough problems.
What’s missing from Scrum?
Although Scrum provides a framework to facilitate good lines of communication and a focus on checking progress towards product goals, it could be argued that it misses some of the critical principles of agility.
If we look back at the summary of agility from this site’s What is Agile article, we can see which aspects of Scrum promote these principles, and which principles are not actively promoted by the wording of the Scrum Guide.
Put people at the heart of the thing you are building, because that’s who you’re building it for.
❌ The Scrum Guide doesn’t really say anything about the people who will use the product. The focus on inspection and adaption in the form of regular meetings encourages internal reflection from team members and stakeholders, but you could do that for an entire year without ever having anything tested by real users. So unless your group of stakeholders attending Sprint Reviews includes real users (which it rarely does), remember to get your product out there in the real world and discuss the feedback you are getting!
Don’t design a final product and plan to build it all at once. Instead, understand the problem that needs to be solved, then build small experiments that help you to work step-by-step towards a solution. Test each experiment in the real world to see if you’re headed in the right direction.
❌ Because the Scrum Guide declines to suggest how Goals or Product Backlog Items should be communicated, it is very possible to follow Scrum by the book but use your Product Backlog to plan a huge final product and use each Sprint to work in waterfall-style phases to build it.Build what you think is the most valuable stuff first (then find out if it was valuable by testing it in the real world).
🤔 The concept of value is covered by the role of the Product Owner, but there is no method to prove that the Product Owner’s perception of what is valuable is correct.Be flexible and ready to respond to change. In practical terms, this means allowing at least one of your constraints - scope, cost or time - to be negotiable. But don’t compromise on quality because you’ll end up regretting it.
🤔 The realities of product development constraints aren’t mentioned at all in the Scrum Guide. But in theory, Scrum should facilitate the ability to respond quickly to change.Work collaboratively. That means talking to and listening to your colleagues as well as the people you’re building the thing for.
✅ Scrum encourages collaborative working (but it is still possible for people working in a Scrum team to work in silos!)Make sure your team has the environment, resources, skills and motivation needed to get the job done.
🤔 Scrum assumes that the people within the team have the skills to get the job done, but provides no guidance to validate if this is the case.Regularly take a step back to think about how you and your colleagues are working together, and discuss how you might be able to improve.
✅ Retrospectives FTW!
In conclusion, while Scrum can be a useful framework, its purposeful incompleteness can sometimes undermine the principles that are meant to be at its core. As long as you are aware of this, and you use the framework alongside a deeper understanding of agile principles, you’re much more likely to have a good Scrum experience, not a bad one.