Scrum Overview in Five Minutes
A quick and simple explanation of Scrum
I am often asked — “What is Scrum, and how does it work?” A proper answer to this question could take several hours.
Sometimes you only have a few minutes before losing their attention and interest, especially if you start using complex terminology.
So when my new team member asked me, “What is Scrum, and how does it work?” I answered this: “Scrum is one of many ways to get the work done. There are hundreds of other ways — yes, hundreds.”
A more expansive and appropriate answer would be that Scrum provides a framework for product management that Scrum Team adjusts to suit their needs. Scrum only provides a structure and not specific step-by-step methods. With Scrum, there are no two teams or instances that have the same approach.
“Scrum is not a process, technique, or definitive method, but rather a framework for developing and sustaining complex products.” — The Scrum Guide.
“Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.” — The Scrum Guide.
In the following section, I will describe my interpretation of Scrum; be aware that this is just one possible variation that I have found to be effective.
In Scrum, things start with a Vision. A vision is a desire that is less uncertain than a dream but vaguer than current realities. It is a dream with stakeholders, followers, and funds. A vision tells us, “why.”
The Vision guides product owners to write features, functions, requirements, enhancements, and fixes.
In our implementation, we call these items as initiatives, epics, stories, tasks, and bugs. Here initiatives and epics are a few categories that will create a path to fulfilling the dream. Work is further explained using stories, tasks and bugs. A story tells one small piece of functionality. There is a specific pattern to write stories that typically include what to do, acceptance criteria and mockups.
At this stage, you have a vision and a initial list of initiatives, epics, stories, tasks, and bugs. In other words, features, functions, requirements, enhancements, and fixes.
The next step is a Sprint Planning in which the work to be performed by the entire scrum team is planned. The team collaborates and identifies items that can be done during the sprint. The team discusses what can be delivered after completion of the upcoming sprint and defines a Sprint Goal. The team also discusses how the work will be completed and delivered to achieve the sprint goal. The product backlog items selected for this Sprint plus the plan for delivering the anticipated increment and the achievement of the Sprint Goal is called the Sprint Backlog.
Now for the next two weeks (assuming a two weeks sprint), the development team meets daily for 15 minutes and plans their work for the next 24 hours. They inspect progress, trends, and discuss any impediments to achieving sprint goals and sprint backlog. These daily discussions are called Daily Scrum.
“The Daily Scrum is held at the same time and place each day to reduce complexity.” — The Scrum Guide
At the end of the sprint, the scrum team and key stakeholders do a Sprint Review in which they inspect what was finished during the sprint and update product backlog as needed. They also collaborate on the next valuable things to do, which becomes an input to subsequent Sprint Planning. During this meeting, the team demos the completed work and gathers feedback. The result of the Sprint Review is a revised Product Backlog that defines the probable Product Backlog Items for the next Sprint.
During this meeting, product owners may also project target delivery dates based on progress to date along with the timeline, budget, potential capabilities, and marketplace for the next anticipated releases of the functionality of the product.
A point to note: The Sprint Review is not a status meeting.
After the Sprint Review and before next Sprint Planning, there is a Retrospective in which the team reflects on how the last Sprint went with regards to people, relationships, processes, and tools. The team identifies items that went well, and items need improvements. The team creates an improvement plan for the next Sprint. The team also plans ways to increase product quality by improving work processes or adapting the definition of “Done.”
The Sprint Retrospective provides a formal opportunity to focus on inspection and adaptation. It helps the team to improve continuously.
I hope this brief overview will create enough interest for you to read more comprehensive articles on Scrum.
I must add that to understand Scrum fully, you will need to experience it. It is easy to talk about Scrum, but very hard to practice it. It is like a rollercoaster ride; you have to take a trip to experience it. No book, video, or virtual technology can provide you with a full understanding.
“Scrum is lightweight, simple to understand, difficult to master.” — The Scrum Guide