3.
1 Scrum Roles
In the Scrum framework, there are three main roles that carry specific responsibilities while
complementing one another. Without a proper understanding of these roles, Scrum loses its
effectiveness. The following is a detailed explanation:
1. Scrum Master
Definition:
The Scrum Master is a facilitator within the Scrum Team who ensures that Scrum processes are
implemented in accordance with its values, principles, and practices. The Scrum Master is not
the “boss” of the team, but rather acts as a servant leader.
Key Responsibilities:
● Ensuring that all team members understand Scrum theory, practices, rules, and values.
● Supporting the Product Owner in managing the backlog for greater transparency and
clarity.
● Helping the Development Team become self-organizing.
● Removing impediments that prevent the team from achieving the sprint goal.
● Acting as a buffer between the team and external distractions without disrupting Scrum
processes.
Required Skills:
● Effective communication and mediation skills.
● Strong knowledge of Agile and Scrum principles.
● Problem-solving and coaching abilities.
Common Mistakes:
● Acting too dominantly, resembling a traditional Project Manager.
● Being passive in addressing the team’s impediments.
Case Example:
In an e-commerce application project, the team struggled due to unclear backlog priorities. The
Scrum Master facilitated a backlog refinement workshop between the PO and the team, which
resulted in a better-ordered backlog and a smoother sprint.
2. Product Owner (PO)
Definition:
The Product Owner is responsible for maximizing the value of the product developed by the
Development Team. The PO represents the “voice of the customer” within the Scrum Team.
Key Responsibilities:
● Defining a clear product vision.
● Creating, managing, and prioritizing the Product Backlog.
● Acting as the primary link between stakeholders (clients, management, end-users) and
the Development Team.
● Ensuring the team understands backlog items clearly.
● Making decisions about product scope, feature priorities, and business value.
Required Skills:
● Business acumen and strategic thinking.
● Strong communication and negotiation skills.
● Ability to prioritize based on value.
Common Mistakes:
● Frequently changing backlog priorities, causing confusion.
● Failing to involve stakeholders in providing feedback.
● Becoming a bottleneck by micromanaging the team.
Case Example:
In an e-learning system project, the PO gathered requirements from lecturers, students, and
administrators. The PO then prioritized login functionality and course material uploads,
considering them the most valuable features for the first sprint.
3. Development Team
Definition:
The Development Team consists of professionals responsible for delivering a functional product
increment at the end of each sprint.
Characteristics:
● Self-organizing: no internal hierarchy; the team decides how best to accomplish work.
● Cross-functional: possesses diverse skills (programmers, testers, designers, analysts)
required to complete the work.
● Small but effective: typically 3–9 members.
Key Responsibilities:
● Selecting backlog items to work on during the sprint.
● Estimating effort (e.g., story points, time).
● Collaborating to produce increments.
● Maintaining quality of code and lightweight documentation.
Common Mistakes:
● Working in silos (e.g., programmers vs. testers) rather than collaborating.
● Waiting for detailed instructions from the Scrum Master/PO instead of being
self-organizing.
Case Example:
In a mobile application project, the Development Team consisted of 1 UI/UX designer, 2 mobile
developers, 1 backend developer, and 1 tester. They collaborated during a two-week sprint to
deliver a working prototype of the login and dashboard features.
3.2 Scrum Events
Scrum prescribes a set of structured events (ceremonies) designed to create regularity and
minimize the need for meetings not defined in Scrum. These events provide opportunities for
transparency, inspection, and adaptation—the three pillars of empirical process control. Each
event has a specific purpose and should not be skipped.
1. Sprint
Definition:
The Sprint is the heartbeat of Scrum. It is a fixed time-box (typically 1–4 weeks) during which a
usable, potentially releasable product increment is created.
Purpose:
● Establishes a predictable rhythm of delivery.
● Encourages focus on short-term goals.
● Provides frequent opportunities for stakeholder feedback.
Responsibilities:
● The team selects what to deliver from the product backlog.
● The increment must meet the Definition of Done (DoD).
● No changes that endanger the Sprint Goal should be introduced.
Common Mistakes:
● Overcommitting too many items in one Sprint.
● Allowing scope creep by adding new features mid-Sprint.
Case Example:
In a 2-week Sprint for a fintech app, the team commits to delivering the login and account
balance features. Despite additional feature requests, they focus solely on these goals until the
Sprint ends.
2. Sprint Planning
Definition:
A collaborative event at the beginning of each Sprint where the Scrum Team defines the work
to be performed.
Purpose:
● Establishes a clear Sprint Goal.
● Selects Product Backlog items for development.
● Creates a plan for how to complete the selected work.
Key Questions Addressed:
1. What can be delivered in this Sprint?
2. How will the work be achieved?
Common Mistakes:
● Vague or unrealistic Sprint Goals.
● Product Owner not prepared with a well-refined backlog.
Case Example:
For a university e-learning system, the Sprint Planning results in a Sprint Goal: “Enable
students to submit assignments online.” The team selects 5 backlog items and estimates their
effort using story points.
3. Daily Scrum
Definition:
A 15-minute daily meeting for the Development Team to synchronize activities and plan the
next 24 hours.
Purpose:
● Inspect progress toward the Sprint Goal.
● Adapt the Sprint Backlog as necessary.
● Improve team communication.
Typical Questions:
● What did I do yesterday to help achieve the Sprint Goal?
● What will I do today?
● Are there any impediments blocking my progress?
Common Mistakes:
● Turning it into a status update for the Scrum Master or PO.
● Exceeding 15 minutes, losing focus.
Case Example:
During a Daily Scrum, a developer reports being blocked by a server issue. The Scrum Master
notes this and takes ownership of resolving it after the meeting.
4. Sprint Review
Definition:
An event at the end of the Sprint where the Scrum Team and stakeholders inspect the
increment and adapt the Product Backlog if needed.
Purpose:
● Demonstrate what has been built.
● Gather feedback from stakeholders.
● Adjust backlog priorities for the next Sprint.
Common Mistakes:
● Treating the Sprint Review as a formal presentation instead of a collaborative
discussion.
● Not inviting stakeholders, missing valuable feedback.
Case Example:
After a Sprint, the team demonstrates the working prototype of a mobile banking app.
Stakeholders request a simpler navigation flow, which the PO records as a new backlog item.
5. Sprint Retrospective
Definition:
A reflection meeting held after the Sprint Review and before the next Sprint Planning.
Purpose:
● Inspect how the last Sprint went in terms of people, processes, and tools.
● Identify improvements that can make the next Sprint more effective.
Activities May Include:
● Discussing what went well, what didn’t, and what to improve.
● Creating an actionable improvement plan.
Common Mistakes:
● Superficial discussions without actionable outcomes.
● Blame culture instead of constructive improvement.
Case Example:
In a retrospective, the team realizes they underestimated testing time. They agree to allocate at
least 30% of future Sprint effort to quality assurance tasks.
3.3 Scrum Artefacts
Scrum defines a set of artefacts that provide transparency and opportunities for inspection and
adaptation. These artefacts represent the work or value in progress and ensure that everyone
has the same understanding of what is being built and why. There are three core artefacts in
Scrum: Product Backlog, Sprint Backlog, and Increment.
1. Product Backlog
Definition:
The Product Backlog is an ordered list of everything that is known to be needed in the product.
It is the single source of work undertaken by the Scrum Team.
Purpose:
● Provides a transparent and evolving roadmap for the product.
● Serves as the foundation for Sprint Planning.
● Ensures alignment between business needs and development work.
Characteristics:
● Dynamic: Continuously updated as new requirements emerge.
● Ordered by priority: Higher-value items are placed at the top.
● Detailed appropriately: Items closer to the top are more refined than those lower down.
Responsibilities:
● Managed solely by the Product Owner.
● Development Team may suggest changes, but PO has the final say on prioritization.
Common Mistakes:
● Poorly refined backlog, causing confusion during Sprint Planning.
● Items too vague or too large (epics without breakdown).
● Frequent reshuffling, disrupting team focus.
Case Example:
In a healthcare app project, the Product Backlog contains features such as patient registration,
doctor scheduling, payment integration, and teleconsultation. The PO prioritizes “patient
registration” first as it is a prerequisite for other features.
2. Sprint Backlog
Definition:
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, along with a plan
for delivering them. It is a highly visible, real-time picture of the work that the Development Team
plans to accomplish during the Sprint.
Purpose:
● Provides transparency on the work the team commits to within the Sprint.
● Acts as a tactical plan for achieving the Sprint Goal.
● Enables the team to track progress daily.
Responsibilities:
● Created by the Development Team during Sprint Planning.
● Continuously updated during the Sprint.
● Only the Development Team can change the Sprint Backlog.
Common Mistakes:
● Treating it as static and never updating after Sprint Planning.
● Overcommitting, leading to incomplete items at the end of the Sprint.
● Lack of visibility for stakeholders.
Case Example:
In an online marketplace project, the Sprint Backlog includes three selected items: product
search, shopping cart, and payment gateway integration. The Development Team breaks them
down into smaller tasks (e.g., design UI, implement backend API, testing).
3. Increment
Definition:
The Increment is the sum of all Product Backlog items completed during a Sprint plus the value
of increments from all previous Sprints. Each Increment must be usable and meet the
Definition of Done (DoD).
Purpose:
● Demonstrates tangible progress.
● Provides a potentially shippable product that can be inspected in the Sprint Review.
● Encourages the team to focus on quality and completeness.
Characteristics:
● Must be usable regardless of whether the Product Owner decides to release it.
● Builds upon previous increments, progressively evolving the product.
● Meets the Definition of Done agreed upon by the Scrum Team.
Common Mistakes:
● Delivering partial features that are not usable (violating DoD).
● Ignoring technical debt, reducing quality over time.
● Misunderstanding increment as “just a demo” rather than a working product.
Case Example:
In a banking app project, after the first Sprint, the Increment delivered is a fully functional login
module. In the next Sprint, the team adds account balance display. Over multiple Sprints, these
increments combine into a usable mobile banking application.