You can also listen Scrum Institute’s Podcast from Apple, Spotify, Castbox and Google Play.
Listen to Scrum Institute Podcast on Apple
Listen to Scrum Institute Podcast on Google Play
Listen to Scrum Institute Podcast on Spotify
Listen to Scrum Institute Podcast on Listen Notes
Listen to Scrum Institute Podcast on Castbox
What Is The Scrum Framework? This Might Surprise You!
What is Scrum? Well, without making things too complicated, the Scrum framework can be deﬁned as the following:
Scrum is an iterative software engineering process to develop and deliver software.
Although the software is the main focus of the Scrum framework, iterative and agile Scrum process can be and is already being applied outside the software industry as well.
Most people in the IT industry believe that the term “Scrum” was coined early in the 2000s as a parallel track of emerging agile software development and delivery trends. That is a piece of incorrect information!
The term “Scrum” was ﬁrst used and published by Harvard Business Review in January 1986. Hirotaka Takeuchi and Ikujiro Nonaka coined the term “Scrum” with their article: The New New Product Development Game. (Yes, two News) You should have a look at “The New New Product Development Game” to see how everything all about Scrum got started!
Scrum can be used in all kinds of software development projects. To develop and deliver complete software packages or only some modules of larger systems — both for products and services of internal and external clients.
The Scrum Framework is a lightweight process. It focuses on increasing the productivity of teams while reducing wastes and redundant activities.
Scrum defines some general guidelines with a few rules, roles, artifacts, and events. Nevertheless, all of these components are critical, serve for specific purposes, and they are essential for the successful use of the Scrum framework.
The main components of Scrum framework are:
- Three Scrum Roles: The Scrum Product Owner, the Scrum Team, and the Scrum Master.
- Five Scrum Events (Scrum Rituals) or Ceremonies: Scrum Grooming (Backlog Refinement) Meeting, Sprint Planning Meeting, Daily Scrum Meeting, Sprint Review Meeting, and Sprint Retrospective Meeting.
- Product Backlog (Scrum Backlog) or Scrum Product Backlog: An artifact that is used to manage and prioritize all of the known requirements of a Scrum project.
- Sprints: Cycles of work activities to develop shippable software product or service increments.
- Sprint Backlog: An artifact to keep track of requirements committed by the Scrum teams for a given Sprint.
Self-organization and unconditional collaboration are critical elements of the Scrum framework. Scrum Teams do no longer require a project manager in a classical sense. With the Scrum framework, the Scrum Master and the Scrum Product Owner share the role and responsibilities of a typical project manager.
Nonetheless, a Scrum Master or a Scrum Product is never allowed to overrule the democratic decision-making capability of a Scrum Team. For instance, only the Scrum team members can jointly commit which ones of highly prioritized Backlog items they will deliver in a Sprint as a software increment.
Another central element with the Scrum framework is the continuous improvement that we enable with “inspect & adapt”. A Scrum Team continuously monitors, inspects, and assesses their artifacts and their use of Scrum framework to adapt and optimize them. These continuous eﬀorts for optimization maximize quality, eﬃciency, client satisfaction, and therefore minimize wastes and overall project risks.
The Scrum framework understands that the requirements are likely to change and they are not entirely known, especially at the beginning of projects.
Every project has unknown unknowns. Sometimes a few, sometimes a lot. The Scrum framework helps us embrace that we can discover and deal with these unknown unknowns only while we are running our projects.
The Scrum Team ﬁrst ﬁne-tunes and granularizes the lower-level or low priority requirements before it implements them. During Scrum Grooming (Backlog Reﬁnement) and Sprint Planning Meetings. Openness for change, continuous optimization, and learning from errors are now becoming integral elements of the whole software engineering lifecycle.
Another cornerstone of the Scrum framework is transparency and direct communication.
The Scrum Product Owner works closely with the Scrum Team to identify and prioritize requirements. These requirements are written down as user stories and stored in the Scrum Product 15 Backlog. The Scrum Product Backlog consists of all tasks that need to be implemented to deliver a working software system successfully.
A Scrum Team is empowered to select the user stories with which they are conﬁdent to deliver within the 2-4 weeks of Sprints. Because the Scrum Team commits its own goals, the team members feel more engaged, and they know that their opinions are listened to. This inclusion of Scrum team members to the natural ﬂow and planning of software projects increases the team morale and subsequently augments the team performance.
Scrum Masters possess another vital role in the Scrum Framework as they work as servant leaders for and with their Scrum Teams.
Scrum Masters are trained facilitators to ensure ﬂawless operation of their Scrum Teams. Sometimes they are master negotiators to protect their Scrum Teams from interruptions and ﬁctive priorities of their stakeholders. Other times they are master communicators to remove or prevent known or anticipated impediments before these impediments bring their teams to dead-end streets. To only call a few of the responsibilities of Scrum Masters. We will cover more about the duties of various Scrum roles later.
The Scrum Framework, in its pure form, is best suitable for highly independent, one team green field or brown field projects.
However, the practical common sense of Scrum professionals did not stop there. With the introduction of additional roles and addendums such as “Chief Scrum Product Owner” and “Scaled Scrum”, it can be used within diﬀerent project conﬁgurations too, including multi-team and geographically distributed project setups. We will cover more about these as well.
For now stay tuned and keep on enjoying the lecture!