Scrum Overview
Scrum is a lightweight framework that is aligned with the agile manifesto values. It's the most widely used agile-aligned framework, used extensively for the development of software.
It is one of the approaches that influenced the creation of the agile manifesto and its authors are two of the creators and original signatories of the agile manifesto for software development.
The Scrum Framework
"A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value."
Often glossed over, the description of scrum is a useful indicator of when it's most appropriate to use and what practitioners should expect when using it correctly.
Scrum is designed for addressing complex adaptive problems. Problems where complexity may exist in a number of different areas - the understanding of the problem, the size of the problem, the technical challenge, the development of the solution etc., and where the nature of the problem is or appears to change. Peoples needs never stand still, they are bound by time - what is important to me now might not be important to me tomorrow. The bigger the problem, the greater the number of stakeholders, the greater the complexity - the longer it will take to develop a solution, so the greater the level of potential change.
Scrum is built upon three empirical pillars: transparency, inspection and adaptation; and its intent is to encourage practitioners to work in way that demonstrates its 5 values: commitment, courage, focus, openness and respect.
As with all approaches that align with agile principles, at the heart of scrum is the concept of breaking down a large problem into small pieces. In particular, scrum is based upon the premise of breaking down the delivery of valuable items of software to users, into product increments that are delivered over regular intervals.
So rather than traditional, waterfall-type approaches that attempt to understand everything upfront then develop the entire solution as one monolithic piece over months or years, scrum focuses its practitioners on developing features that are going to deliver the greatest value to users at that point in time and incrementally build upon those in subsequent product releases.
The Scrum Artefacts
Scrum defines three artefacts that are used to help progress items of work to develop a product.
The product backlog is a list of all the things that product owner would like the development team to work on.
The sprint backlog is a list of things taken from the product backlog, that the development team has agreed with the product owner that they will work on during the current sprint.
The product increment is the result of the work the development team does during the sprint.
The Scrum Roles
The people that work in a team that are working to Scrum are the Scrum Team.
The scrum team comprises of just three roles: the Product Owner, the Scrum Master and the Development Team.
The Product Owner owns the product. They are responsible for deciding what the product should be. They represent the users of the product and must understand their needs and prioritise what is most valuable to them, so that the development team can build products that are of most value to users at any point in time.
The Scrum Master owns scrum. They own the way of working and are responsible for ensuring that the whole scrum team work as effectively as possible to scrum. They are a servant-leader to the team, supporting the team by removing blockers are providing the scrum team with what they need to deliver the product increment.
The Development Team do the work to turn the list of things stakeholders want into actual products. They do their work during the sprint and build the product incrementally over multiple sprints. The development team comprises all of the capabilities and has the capacity to develop the product.
The Scrum Ceremonies
The process that a Scrum Team works to comprises 5 ceremonies: the Sprint, the daily Scrum, Sprint Planning, the Sprint Review and the Sprint Retrospective.
The Sprint is at the heart of scrum. Its a fixed-time period during which all the work to deliver a product increment is carried out. The scrum guide suggests that a sprint should be between a maximum of 4 weeks long, but can be less. Once you decide upon the duration of the sprint, it shouldn't ever change. Sprints follow one another sequentially, when one sprint finishes the next sprint starts - there is no gap between sprints.
The team start the sprint with a sprint planning meeting to agree what they're going to work. Sprint planning is a time-boxed meeting - the sprint guide suggests a maximum of 8 hours for a four week sprint. (However we'd recommend you aim for a maximum of 1 hour per week of sprint, so for a two week sprint aim for a maximum of 2 hour for your sprint planning session.)
In order to ensure that the team keeps on track to deliver the agreed product increment, every day the team holds a daily scrum. This usually happens first thing in the morning and is time-boxed to a maximum of 15 minutes. During the daily scrum each member of the team describes what they have been working, what they are planning to work on and they share any problems that might stop them from progressing as planned.
At the end of the sprint the team holds a sprint review where they demonstrate the work they have done during the sprint with the stakeholders. The sprint review is not a formal progress reporting meeting but an informal sharing of what has been built to check that it is of value and to engage stakeholders for feedback so that any changes to the product backlog for upcoming work can be made.
Following the sprint the scrum team holds a sprint retrospective. During the retrospective the scrum team reflects on how they worked during the sprint with a view to identify any changes that they can make to improve they way of working during future sprints.
This overview just provides a description of the key attributes of the scrum framework as defined in the scrum guide. Implementing scrum based on just these attributes is possible, but there are activities that the scrum guide touches on but doesn't define. Some are important as they act as enablers for scrum. The most significant is around creating and managing a product backlog through backlog refinement. Another useful activity is how work is managed during a sprint. Similarly, scrum doesn't define how to plan or forecast.
All of these are necessary in order to develop digital services, but none are specific to scrum.
