Skip to content

Scrum

Scrum is an iterative and incremental Agile framework for managing product development. It is not a technique for creating software (like XP) but a framework for organizing projects and managing work.

  • Empirical Process Control: Scrum is based on three pillars that uphold empirical process control:

    1. Transparency: Providing visibility to those responsible for the outcome (e.g., common language, shared definitions).

    2. Inspection: Frequently checking the product and progress towards goal to detect undesirable variances.

    3. Adaptation: Adjusting the process or material if inspection reveals deviations outside acceptable limits.

  • Time-boxing: Development occurs in fixed-length iterations called Sprints (typically 2-4 weeks), ensuring a regular cadence of delivery.

Scrum Roles

Scrum defines three specific roles for a Scrum team, avoiding traditional titles like "Project Manager" to emphasize self-organization.

A. The Product Owner

The Product Owner is the single person responsible for maximizing the value of the product and the work of the Development Team. They define what will be delivered and in what order via the Product Backlog.

Key Responsibilities:

  • Acts as the "single voice of the customer."
  • Manages the Product Backlog (ordering and prioritizing items).
  • Decides what will be built and in what order.
  • Accepts or rejects work results.
  • Communicates the product vision to the team.

Activities:

  • Identifying relative value on the PBIs (Product Backlog Items).
  • Communicating the vision of the business to the team and the vision of the team to the business.
  • Defining available budget.
  • Setting goals for the sprints and releases.
  • Participating in the sprint planning and release planning meetings.
  • Elaborating PBIs on a just-in-time basis with the team.
  • Accepting PBIs.
  • Accepting the sprint/release.
  • Deciding when to release.
  • Defining the features of the product via PBIs (mainly stories).
  • Setting development schedule by ordering the product backlog.
  • Adjusting PBIs and prioritising every sprint as needed.
  • Ensuring return on investment.
  • Gaining insight and assurance the product is meeting its goals through deep and broad feedback.

B. The ScrumMaster

The ScrumMaster is a servant-leader and coach for the team. They do not have authority over the team but have authority over the Scrum process. They facilitate the adoption of Scrum through coaching and guidance, leading the team to high-performance and using the framework to inspect and adapt.

They also work at the organizational level, mitigating impediments towards adopting an organization-specific Scrum approach.

Through activities and coaching, the ScrumMaster helps the development team overcome impediments, resolve internal and external issues, and make best use of the lightweight and flexible framework.

External interference should be eliminated, as the ScrumMaster acts as a team shield in line with Agile Manifesto principle number five: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

Key Responsibilities:

  • Coaching: Guides the team in self-organization and cross-functionality.
  • Shielding: Removes impediments (obstacles) and protects the team from external interference.
  • Facilitator: Ensures Scrum events (meetings) take place and are effective.
  • Servant-Leader: Helps the team perform at their highest level rather than directing their tasks.

Activities for Success:

  • Establishing Scrum practices and rules, shielding the team, and removing obstacles.
  • Ensuring that the Scrum team is fully functional and productive.
  • Enabling close cooperation across all roles and functions.
  • Ensuring that the Scrum process is followed, including effective daily Scrum meetings, sprint reviews, retrospectives, and planning meetings.
  • Leading and coaching the organization in adopting Scrum.
  • Assisting the product owner and finding effective product backlog management techniques.

C. The Development Team

The Development Team is a cross-functional, self-organizing group of professionals who deliver a potentially shippable Increment. They define how to deliver what has been asked for and how long it will take via the Sprint Backlog. The team is a self-organizing, cross-functional, and collaborative entity that aims to deliver the goals agreed with the Product Owner.

Key Characteristics:

  • Self-Organizing: The team decides how to turn the Product Backlog into working product; no one (not even the ScrumMaster) tells them how to build it.
  • Cross-Functional: The team possesses all the skills necessary to create the product increment (e.g., coding, testing, analysis, design).
  • Size: Typically 5 to 9 people (or 7 ± 2). Small enough to communicate, large enough to complete significant work.

Self-organization is a critical and evolving characteristic of the Development Team. The team determines the best manner to realize the requirements defined and prioritized by the Product Owner in the form of the Sprint Goal, in line with Agile Manifesto principle number 11: The best architectures, requirements, and designs emerge from self-organizing teams.

Responsibilities:

  • Working with the Product Owner, ensuring that PBIs are understood and realized appropriately.
  • Defining emergent architectures while maintaining quality at the agreed level.
  • Being self-organizing, cross-functional, with no predetermined roles.
  • Consisting of seven plus or minus two people – all skills required to get PBIs to 'done'.
  • Using lots of face-to-face communication.
  • Being responsible for organizing tasks and committing to work.
  • Having authority to do whatever is needed to meet commitment.
  • Demonstrating work results to the Product Owner and stakeholders.
  • Having the right to do everything within the boundaries of the delivery standards and guidelines to reach the sprint/release goal.

Scrum Artefacts

Artefacts represent work or value to provide transparency and opportunities for inspection and adaptation.

A. Product Backlog

  • An ordered "to-do" list of everything that might be needed in the product. It is dynamic and evolves as the product evolves.
  • Content: Features, functions, requirements, enhancements, and fixes. Items are often written as User Stories.
  • States of Items: Backlog items move through states such as Ready for consideration, Ready for refinement, and Ready for implementation.
  • Management: The Product Owner, with assistance from the ScrumMaster, team, and stakeholders, is responsible for defining, elaborating, sequencing, and communicating work. Items are prioritized by value, with higher-value items at the top. This involves value-based decomposition and prioritization.
  • Refinement: Items vary in clarity and are refined through feedback and investigative work (e.g., spikes). The backlog evolves via refinement (grooming), where PBIs are broken down, added, removed, modified, and re-prioritized based on changing needs.

B. Sprint Backlog

  • The set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal.
  • Ownership: Owned solely by the Development Team. It makes visible all the work necessary to meet the Sprint Goal.
  • Task Breakdown: High-level items are often broken down into tasks of 1–2 days duration.

C. Potentially Shippable Product Increment

  • The sum of all Product Backlog items completed during a Sprint and the value of the increments of all previous Sprints.
  • Quality: It must be in a usable condition regardless of whether the Product Owner decides to release it. It must meet the team's Definition of Done.

Scrum Activities (The Process)

The Scrum lifecycle revolves around the Sprint, a time-boxed iteration (typically 2–4 weeks) producing a potentially releasable increment. Sprints form a cadence coordinating events like planning, reviews, and retrospectives. Each Sprint has a mutually agreed Sprint Goal, which should not be altered mid-Sprint to avoid disorientation.

A. Sprint Planning

  • Timing: Held at the beginning of each Sprint.
  • Purpose: To answer two questions: What can be delivered in this Sprint? (Selecting items from the Product Backlog). How will the work be achieved? (Decomposing items into tasks).
  • Sprint Goal: The team agrees on a shared objective for the Sprint (e.g., "Implement user roles").
  • Process: The Product Owner defines the Sprint Goal and selects PBIs. The Development Team commits to the goal, and the Product Owner commits not to add changes during the Sprint. The selected PBIs, tasks, and estimates form the Sprint Backlog, which evolves as estimates are updated.

B. Daily Scrum (Stand-up)

  • Timing: A 15-minute time-boxed event held every day.
  • Purpose: To synchronize activities and create a plan for the next 24 hours.
  • The Three Questions: Team members typically answer:
    1. What did I do yesterday?
    2. What will I do today?
    3. Do I see any impediment (blocker)?
  • Additional Questions (Optional): Have any additional tasks been identified? Have you learned or decided anything relevant to the team?

C. Sprint Review

  • Timing: Held at the end of the Sprint.
  • Purpose: An inspect-and-adapt activity where the team demonstrates the completed work (Increment) to stakeholders.
  • Outcome: Feedback is gathered, and the Product Backlog is adapted if necessary.

D. Sprint Retrospective

  • Timing: Held after the Sprint Review and before the next Sprint Planning.
  • Purpose: The team inspects how the last Sprint went regarding people, relationships, process, and tools.
  • Outcome: Identifies and commits to actionable improvements for the next Sprint.

E. Product Backlog Refinement (Grooming)

  • Description: The ongoing process of adding detail, estimates, and order to items in the Product Backlog.
  • Activities: Includes refining (breaking down), estimating, creating, and prioritizing items. The team decomposes large PBIs into smaller, ready items (ideally completable in 2–5 days). Prioritization ensures the backlog is ordered for planning, with less precise estimates for lower-priority items.

Key Definitions & Concepts

  • Product Backlog Item (PBI): An item in the Product Backlog, often expressed as a User Story, feature, bug fix, or enhancement.
  • Definition of Done (DoD): A shared understanding of what it means for work to be complete. It ensures transparency and quality. For example, "Code reviewed, Unit tested, Integrated, and Accepted".
  • Velocity: An estimate of how much work (often measured in story points) a team can complete in a single Sprint.
  • Sprint Goal: A short statement of what the team plans to achieve during the Sprint, providing focus and coherence.
  • Self-Organization: Teams manage their own work rather than being directed by a manager. They coordinate tasks and make decisions by consensus.

Questions

These questions cover the Scrum process, roles, and its application in project management.

Process and Methodology:

  • What is Scrum Process? Explain Agile Project Management in detail.
  • Demonstrate scrum approach of agile methodology with a neat diagram.
  • What is Scrum? How do you implement scrum? Explain.
  • Why Scrum? Illustrate Applying Scrum for project development.
  • Explain the Scrum activities and process.

Roles and Responsibilities:

  • Describe the primary roles in Scrum and what are their responsibilities.

Business Value:

  • Explain Business value through Collaboration and Empirical Management for developing application using scrum.
  • Why Current System Development Methodologies Don’t Work? Why Does Scrum Works? Discuss.