Software Engineering: Scrum for Software Development

The Pigs and Chickens: Scrum Roles

• The Pigs and Chickens analogy from Scrum: the Pig(s) represent committed participants in the work (Product Owner, Scrum Master, and the Developers); the Chicken(s) are those who are involved but not committed.
• The joke from the transcript: a Pig would be committed, while a Chicken would be merely involved, illustrating the distinction between core Scrum roles and external stakeholders.
• Practical takeaway: after this class, don’t be offended if someone calls you a pig or a chicken; in Scrum terms, pigs are the committed roles and chickens are others.

What Is Scrum?

• Definition: a general-purpose, team-based framework to develop complex systems and products.
• Focus: work management and team dynamics; not necessarily limited to software development.
• Origin: originally published in the Harvard Business Review; almost didn’t mention software; connected to the idea of the "New Product Development Game".
• Adoption: widespread application in software development.
• Critique: Scrum lacks explicit engineering practices (e.g., pair programming, unit tests, static analysis, code reviews) when used in isolation.
• Nature: agile process that is iterative and incremental.
• Sprint concept: the product is developed in a sequence of sprints; each sprint releases a fully tested version; each release adds functionality.
• Roles: Product Owner, Scrum Master, and Developers (team members).
• Artifacts: Product Backlog and Sprint Backlog.
• Notable implication: Scrum defines what to do (and who does it) but is often most effective when complemented by engineering practices.

Scrum with Engineering Practices (Augmented Scrum)

• Scrum plus software engineering practices has delivered high-quality products.
• Examples of engineering practices often paired with Scrum:
  • Unit testing or Test-Driven Development (TDD)\text{,}
  • Pair programming\text{,}
  • Continuous integration.
• Caution: Scrum without engineering practices may be dangerous or ineffective according to critics.
• Scrum Timeline (high-level):
  • Up-front planning to produce an initial, prioritized Product Backlog describing what the product needs to do (a list of user stories).
  • Then a series of sprints, each releasing a fully tested increment of the product.
  • Planning Sprint1, Sprint2, Sprint3, …, Sprintn.
• Sprint rhythm:
  • Time-boxed development period (iteration).
  • Bite off small bits of the project and finish them before taking on more work.
• Sprint length (typical):
  • 1{-}4 \text{ weeks} (time-boxed).
  • Popular length: 2 \text{ weeks}.
  • Some teams start with 1 \text{ week} sprints.
• Key takeaway: a disciplined cadence with integrated engineering practices tends to yield better outcomes.

Scrum Rhythm: Time, Sprints, and Planning

• Planning and backlog creation:
  • Initial up-front planning to produce a prioritized Product Backlog of user stories describing what the product needs to do.
  • Then execute a sequence of sprints, each delivering a fully tested increment.
• Sprint cycle terminology:
  • The Sprint (the iteration): development period where a bite-sized amount of work is completed.
  • Time-boxed: duration set before it begins (see above for typical lengths).
• Sprint goals and increments:
  • Each sprint releases a fully tested increment with added functionality.
  • Some stories may be incomplete at sprint end and are carried forward into future sprints.
  • In rare cases, a sprint can be canceled if external circumstances negate the sprint goal.
• Planning cadence:
  • Up-front planning to prepare the initial backlog; ongoing sprint planning as needed.
• Spikes (technical spikes):
  • Time-boxed research or prototype work to address challenging technical problems.
  • Spikes may or may not deliver tangible functionality, but help reduce risk.

Scrum Roles and Events (Overview of Roles)

• Core Scrum roles (three):
  • Product Owner: represents stakeholders and customers; owns the Product Backlog; communicates status; negotiates tradeoffs between functionality, quality, and effort (cost, schedule).
  • Scrum Master: Scrum expert, advisor, and coach; guides the team toward higher cohesion, self-organization, and performance; monitors process and progress; acts as a facilitator and impediment bulldozer; leadership by influence (not a boss).
  • Developer: self-organizes to deliver the user stories; does all development work (analysis and design, coding, testing, documentation); responsible for estimating stories and tasks; owns how to do the work; supports shared/collective code ownership; avoids "not my job" mentality; entire team is responsible for the product code.
• Clarification: these are distinct from other non-Scrum roles (e.g., administrator, marketing director, customer, user, etc.).
• Typical team size: 5{-}9 members (rule of thumb: 7 \pm 2).
  • Too few: may lack needed skills to complete stories.
  • Too many: communication overhead increases.
• Scrum of Scrums (Meta Scrum):
  • When there are multiple Scrum teams (each 5–9 members).
  • Works to resolve dependencies, risks, impediments, and assumptions across teams.
  • Daily Meta Scrum: ambassadors from sub-teams report completions, next steps, and impediments on behalf of their sub-teams.
  • Impediments in Meta Scrum typically involve cross-team coordination challenges (interfaces, responsibility boundaries) and are moved to the Meta Scrum backlog for handling.

Sprint Events and Time-boxed Activities

• Sprint Planning Meeting (two main questions):
  • (1) What will we do? Identify a set of stories the whole team can deliver by the end of the sprint; Product Owner presents stories; team discusses each story; reviews acceptance criteria; identifies dependencies.
  • (2) How will we do it? Decompose selected stories into tasks; obtain input from users; design screens; update databases; perform black-box testing of the new feature; draft help text; run release scripts; Product Owner available to answer questions.
  • A high-performing team typically identifies about 60{-}70\% of tasks during planning.
• Estimation methods: units for effort estimation include task hours, task points, or task counts.
• Daily Scrum (Stand-up):
  • Time-boxed to around 15 \text{ minutes}; held daily at or near the start of the work day.
  • Focused on quick status updates: what was done since the last stand-up, what will be done before the next stand-up, and any impediments.
  • In practice: smaller teams may have the stand-up with only development team members; the goal is to keep lines of communication open and to avoid solving big problems during the stand-up.
• Backlog Grooming / Story Time: (Backlog refinement)
  • Work with upcoming stories (not the current sprint’s stories).
  • Maintain a collection of small, well-understood stories at the top of the backlog.
  • Activities: assign sizes to stories; break large stories into smaller ones; define/refine acceptance criteria for stories.
  • Recommendation: about 1 \text{ hour per week}, regardless of sprint length.
• Sprint Review / Demo (End of Sprint):
  • Public demonstration of working software to stakeholders.
  • Celebrate accomplishments and gather feedback.
  • Invite all stakeholders; demonstrate completed stories; report which stories did not get completed;
  • Take notes on stakeholders’ reactions to the live product.
• Retrospective (End of Sprint):
  • Reflect on what was learned during the sprint.
  • Example reflections from the transcript: "Not enough time for testing"; "Integrating subsystems was painful"; "Fixing bugs kept us from working on new features".
  • Goal: identify specific improvements and create an action plan to implement changes.
  • Recommendation: about 1{-}2 \text{ hours per week} of development time allocated to implementing improvements.
• Additional notes on cadence (from the weekly schedule in the transcript):
  • Planning sessions often occur at the start of each sprint (commonly around two hours).
  • Daily stand-ups are 15 minutes long and occur every day of the sprint.
  • Sprint Review/Demo is around 30 minutes at the end of the sprint.
  • Story Time and Retrospective are typically 1 hour each, scheduled within the sprint.

Practical Implications and Real-World Relevance

• The combination of Scrum with engineering practices addresses the common criticism that Scrum alone lacks engineering rigor.
• The cadence of planning, development, review, and retrospection fosters continuous feedback, risk reduction, and incremental value delivery.
• Clear roles and responsibilities help balance ownership, authority, and collaboration while avoiding micromanagement (Scrum Master as facilitator rather than boss).
• The concept of spikes introduces a disciplined way to tackle difficult technical problems without derailing the sprint goals.
• The use of backlog grooming ensures there is a ready backlog with well-understood stories, enabling smoother sprint planning and feasibility assessments.
• The meta-scrum and cross-team coordination mechanisms illustrate how Scrum scales: maintaining alignment while preserving team autonomy.
• Ethical and practical implications:
  • Emphasizes accountability (pigs) and collaboration (teams) over blame or siloed work.
  • Encourages transparency with stakeholders through frequent demos and feedback loops.
  • Highlights the importance of sustaining engineering practices (testing, CI, pairing) to deliver quality software.

// LaTeX notes used in calculations/expressions:

• Sprint length: 1{-}4 \text{ weeks}
• Popular sprint length: 2 \text{ weeks}
• Team size: 5{-}9
• Typical team size (7 ± 2): 7 \pm 2
• Planning task identification: 60{-}70\% of tasks identified during Sprint Planning
• Weekly retrospective time recommendation: 1{-}2 \text{ hours per week}
• Stand-up duration: 15 \text{ minutes}
• Sprint Review duration: 30 \text{ minutes}
• Backlog sizing and time-boxing considerations are described in qualitative terms (no fixed numerical formula beyond the scales above).