Scrum Framework: Roles, Events, and Project Benefits

Posted on Jan 19, 2025 in Software Engineering

Introduction to Scrum

  • Self-organization is key
  • Collaboration instead of working against each other
  • Fewer but clearly defined roles and rules
  • Scrum is an empirical approach, a learning approach
  • Inspired by practices in Rugby and Japan

Classic Projects vs. Agile Projects

Classic Projects

  • A lot of documentation required
  • Long time between releases
  • No changes expected
  • Slight communication and collaboration (handover)
  • Bad quality, missing functionality, and dissatisfaction

Agile Projects

  • Only needed documentation required
  • Development in short cycles
  • Changes are expected (positive)
  • High communication and intense collaboration
  • Better quality, committed functionality, highest satisfaction

Scrum Team: 5-11 + Master + Owner

Scrum Master

  • Manages the process
  • Aligns with the organization
  • Supports the close collaboration between roles and functions
  • Protects the team from interferences
  • Removes impediments
  • Assures productivity of the team
  • Responsible for keeping the Scrum values and processes
  • Is a moderator and coach

Product Owner

  • Responsible for the success
  • Accepts or denies results
  • Adjusts sprint criteria depending on the market
  • Defines release data and content
  • Only one who can stop a sprint
  • Responsible for acceptance criteria
  • Defines product features
  • Responsible for the product

Development Team (3-9)

  • Members should exclusively work as team members
  • Responsible for their goals
  • Estimates time of development
  • Cross-functional – All know-how is in the team
  • Only skills count, not roles
  • Organizes itself
  • Develops and tests the products
  • Membership should only change at the end of a sprint

Scrum Events

1. Sprint Planning

  • Identification, prioritization, discussion, specification, estimation, alignment
  • Initiated by the Product Owner
  • No official Scrum meeting
  • Up to a maximum of 10% of the team capacity per sprint
  • Supports the dialog between the Product Owner
  • Refinement meeting reduces time of sprint
  • Can be used for estimation
  • Product Owner organizes the sprint planning, what to do
  • Product Owner leads the sprint planning meetings
  • Product Owner presents the development team the requirement for the next sprint
  • Development team can clarify open points to estimate the requirements
  • Development team estimates the requirements
  • Based on chosen requirements the sprint goal will be planned

2. Sprint Goal

  • Defined by the development team together with the Product Owner
  • Definition takes place in the sprint planning by choosing elements to develop
  • Helps the development team to focus and raise motivation
  • Describes the result of the sprint
  • Helps to prioritize

3. Sprint

  • Time box of 2 to 4 weeks
  • Always have the same time box and follow each other directly
  • At the end of every sprint there will always be a potentially shippable product increment
  • PSPI will be designed, developed, and tested during a sprint
  • Every sprint should have a sprint goal

4. Daily Scrum

  • What did I do yesterday? What will I do today? What problems have I had?
  • Daily 15 minutes, same time, same place, reduces complexity
  • Meeting should avoid other non-necessary meetings
  • Only development team members and the Scrum Master talk
  • Meeting is not for problem solving, only for problem identification
  • Solve impediments
  • Meeting open to listeners
  • Product Owner can participate, to answer questions or be informed

5. Sprint Review

  • Development teams presents the client and Product Owner the results of the PBI
  • Product Owner checks the result based on the acceptance criteria of the PBI
  • Result integrated into product or result goes back to product backlog. Product Owner decides how to proceed
  • Presentation of the increment by the development team
  • Product Owner accepts or rejects the increment
  • The development team receives direct feedback from the client
  • Client identifies with the Product Owner the requirements for the next sprint
  • Review meeting lasts a maximum of 4 hours for a 4 week sprint, proportionally shorter for shorter sprints

6. Sprint Retrospective

  • Collect feedback by looking back
  • Cluster for topic
  • Define priorities
  • Discuss topics
  • Outcome: Action measures to improve our errors/efficiency
  • What could be done better?
  • Whole Scrum team participates in the retrospective
  • 3 hours for a 4 week sprint
  • Negative and positive topics are to be discussed