Some people are far too busy to read all 19 pages of The Scrum Guide. So, here's an abbreviated version that I banged out in my lunch hour!
Scrum is a lightweight “Agile” framework for getting complex stuff done in the real world. Scrum is widely used in software development but it’s roots are in manufacturing and it can be used to build software or rocket ships and empower sales teams, marketing teams, HR teams and other service teams.
Scrum is a simple framework which assists your teams becoming “Agile”, in other words it’s a framework which emphasises the importance of teamwork, prioritises getting stuff done over following pointless processes, expects your teams to react to change and feedback and finally it encourages your teams to deliver what the customer wants and needs now rather than what somebody thought they originally asked for six months ago.
If none of this is of interest to you then you can stop reading now because although Scrum is simple to understand it is surprisingly difficult to implement successfully because it involves fundamentally changing how teams work together, how teams interact with management, how teams interact with the business. To make things even worse, implementing Scrum successfully in an organisation also requires leadership and business stakeholders to fundamentally change their behaviour as well. On the plus side your teams should become more productive or at least deliver more value, your stakeholders will have an increased chance of getting what they actually want and leadership will be able to spend more time leading and doing the important stuff as they are no longer required to micro-manage.
Scrum is an “empirical process framework”, which sounds impressive but just means that it’s based on transparency, inspection and adaptation. In other words the organisation is encouraged to be open and honest and have a common language and a shared understanding of what’s happening so that everyone is on the same page. The organisation then uses this shared understanding to frequently inspect and adapt what work is being done and how it is being done. Scrum will not magically solve your problems but Scrum does give you timely visibility on what your problems are and thus allows you to focus on fixing problems and making better decisions, assuming you have the courage and commitment to follow through.
Scrum is based around empowering small teams because small teams are more productive, creative and produce higher quality work. Scrum teams focus on getting things done, not almost done or ready to test, so that we can accurately judge our progress towards defined business goals and receive feedback from stakeholders and then adapt our products, services, processes and/or plans as necessary.
The Scrum Framework
The Scrum Framework is formed of 3 artefacts, 5 events and 3 roles and a few other things. These roles, events and artefacts are the minimum that you need to be successful with Scrum in other words you can add things but you can’t take them away.
The Product Backlog
Everything that you want to do to accomplish a goal or to realise a product is split into individual deliverables or features or changes or tasks and then put into a Product Backlog. This can be updated, added to and reprioritised at any point.
The Product Owner
One person responsible for the vision of what it is you are trying to achieve and deciding what goes in the Product Backlog and where it should be prioritised. Other people in the business can try and influence the Product Owner but they have the final say.
The Development Team
The people responsible for delivering what the Product Owner wants. Once the Product Owner has prioritised the work, the Development Team are responsible for getting it done in the best way they see fit, within the boundaries defined by the Scrum Framework. They take shared responsibility for technical decisions without day to day management because that’s how to get the best out of people doing complex tasks. The recommended team size is between 3 and 9 but current data suggests that 4-5 is optimal.
The Scrum Master
A coach and mentor for the team with an excellent understanding of Agile and Scrum. They constantly encourage the team and the organisation to improve and work within the Scrum Framework without directly managing them in any way.
The Development Team deliver things iteratively in “Sprints”, which are simply set intervals of time between one week and one month.
Each Sprint begins with Sprint Planning where the Scrum Team (i.e. the Product Owner and the Development Team assisted by the Scrum Master) plan what they are going to do this Sprint and how they are going to do it.
The Sprint Backlog
The output of Sprint Planning is the Sprint Backlog, i.e. a prioritised list of everything that the team will get done in the Sprint and a rough breakdown of how they will get it done.
The Daily Scrum
Every 24 hours the Development Team meet up to inspect and adapt their plan for the Sprint based on their progress so far and any discovery that has been made.
The Sprint Review
At the end of the Sprint the team and any interested stakeholders meet up to review progress and discuss possible next steps based on what they now know. Stuff which isn’t 100% done is put back onto the Product Backlog and can be reprioritised.
The Sprint Retrospective
After the Sprint Review the Scrum Team inspect and adapt their working processes and come up with at least one improvement to implement next Sprint. Even if it’s small, 52 small incremental improvements can make a huge difference in a year.
Everything that has been delivered from all Sprints so far. It’s not a great name, I know.
Project managers don’t exist in Scrum and management don’t actively man manage the team but assist by removing organisational impediments and providing clear direction on company culture, values and working practices.
Definition of Done
A comprehensive list of what “done” means so everyone understands what it means when the team says something is done. Typically this will be updated as the team matures.
Whilst delivering work in the current Sprint the team will also work on understanding the highest priority items in the Product Backlog so they are ready to be worked on.
The Sprint Goal
Each Sprint should have an overarching Goal to focus the team and allow negotiation.
Sprints and other events are timeboxed, i.e. restricted to a fixed amount of time to encourage focus and avoid gold plating.
Cancelling the Sprint
If the Product Owner decides that the Sprint Goal is redundant then the team should cancel the Sprint, reprioritise and immediately start a new Sprint.
The Development Team are responsible for monitoring progress towards the Sprint Goal just as the Product Owner is responsible for monitoring progress towards Product Goals.
Teams which are great at Scrum tend to display the values of Courage, Focus, Commitment, Openness and Respect. Without these values you will struggle to be successful with Scrum.
Scrum has been developed over many years, with input from countless people working on thousands of real-world projects. The co-authors of the codified Scrum Guide are of course Jeff Sutherland and Ken Schwaber and The Scrum Guide has been through several iterations by now with a formal review process in place to capture feedback from the Scrum community.
I wrote this Abbreviated Guide in an hour to see if I as a Professional Scrum Trainer could summarise The Scrum Framework in 3 pages. Any errors are entirely my own but I’d like to think due to time constraints and poor typing rather than a fundamental lack of understanding.
The Scrum Guide
This is my own lightweight, light-hearted take on Scrum. If you’d like to know more then you should absolutely start by reading the actual Scrum Guide here which is more precise and more complete and what's more it’s only 19 pages…