CIS 3500

Introduction to
Software Engineering or
"how to JOYFULLY BUILD
with a TEAM"

Prof. Jérémie Lumbroso, Ph.D.

lumbroso@seas.upenn.edu

⚠️➡️ RIGHT NOW, go to https://sli.do

Code #27232327 

LECTURE 6:
Agile & User Stories—Evolving Requirements Iteratively

Sli.do Requires An Email

⚠️➡️ RIGHT NOW, go to https://sli.do

Code #27232327 

1

2

3

4

5

6

7

8

9

10

Please enter the table number you are sitting at?

⚠️➡️ RIGHT NOW, go to https://sli.do

Code #27232327 

Recap of Lecture 1 (Bridge)

Waterfall Fiasco → Agile “Rescue”

  • Healthcare.gov meltdown: Big-bang release, shifting requirements, no iteration.
  • “Tech Surge” used daily stand-ups, frequent fixes: a small taste of Agile in action.
  • Waterfall historically works well for stable, mass-production contexts (Fordism). Modern software changes too fast.

Agenda

  1. Agile Mindset & Overview
    • From Lean/Toyota → Agile Manifesto
    • Roles in Agile (brief mention)
  2. User Stories & Backlogs
    • Epics vs. Stories
    • Acceptance Criteria & Tests
  3. Hands-On Group Task: Writing/refining user stories, using ChatGPT
  4. Q&A / Wrap-Up

Paper Airplane Challenge

Practicing being a team

Paper Airplane Challenge

“You Have 7 Minutes… Go!”

  • We’re starting with a quick, hands-on challenge to see how you work together under pressure.

  • The details are on the next slides. Ready yourselves—when time starts, you’re on your own.

  • Be Prepared To Form Teams

The Mission & Setup

Mission:

In 7 minutes, produce the highest possible number of paper airplanes that meet our basic quality requirements.

Groups: ~4-6 students per team

Time: 7 minutes total

  • Form teams quickly—move to sit together or turn your chairs around so you can collaborate.

  • Your job: make as many acceptable planes as possible before time runs out.

Acceptance Criteria

  • Must-Fly Distance: Plane must fly at least 2 meters

  • Must-Have: Your team’s name or logo clearly visible

  • We’ll do a quick flight test at the end. If it doesn’t reach 2 meters, it doesn’t count.

  • If it’s not marked with your team’s name or logo, it doesn’t count.

  • Everything else (design, folding technique, decoration) is completely up to you.

JUDGING (2 mins)

  • One judge from
    • Table 1 -> goes to Table 10
    • Table 2 -> Table 1
    • Table 3 -> Table 2
    • ...
    • Table 10 -> Table 9
  • Judge must count valid planes
  • Judge must submit count on Sli.do
  • Judge will give count when called

Results

  • Team 1: 30  (6 people)
  • Team 2: 28  (6 people)
  • Team 3: 38  (5 people)
  • Team 5: 43  (6.5 people)
  • Team 6: 18  (5 people)
  • Team 7: 38  (5 people)
  • Team 8: 26  (4 people)
  • Team 9: 34  (3 people)
  • Team 10: 16  (5 people)

No Roles, No Process

Rules for Round 1:

  • No assigned roles (no designated leader, tester, or anything else).

  • No sprints or timeboxes. Just do whatever you want.

  • 7 minutes total.

  • “You don’t have a ‘Scrum Master,’ there’s no mandatory planning—just get to work.”

  • “You can coordinate however you like (or not). We won’t intervene.”

Ready, Set… Go!

What are we trying

... to solve?

"This is How IT Projects Really Work" posted via Dashi Blog on February 22nd, 2004

From:

From The Oregon Experiment (1975)

A Few “Agile”
Definitions

Before we get started

“Agile”: Where it fits in with other product management methods?

  • Agile is a kind of iterative approach for building software in short cycles.
  • Scrum is a kind of Agile framework with sprints and specific roles.
  • Kanban is a kind of Agile method focusing on continuous flow and WIP limits.
  • Lean is a kind of production philosophy (originating with Toyota) emphasizing minimal waste and rapid feedback—foundational to Agile thinking.

User Stories & Related Terms

  • Product Backlog is a kind of prioritized list of everything the team might build (features, bugs, etc.).
    • Epic is a kind of large requirement—often split into multiple stories.
      • User Story is a kind of small, user-focused requirement typically completed in one sprint.
        • Task is a kind of technical sub-step that helps implement part of a user story.
           
  • Acceptance Criteria is a kind of ‘definition of done’—specific conditions a user story must satisfy.
  • Acceptance Test is a kind of test verifying each acceptance criterion is met (often written as “Given–When–Then”).

Agile

What everyone uses in software

Agile Manifesto (Historical Context)

We are uncovering better ways of developing software by doing it and helping others do it.

Published 2001 by 17 developers (incl. Ward Cunningham)

  • 4 core values:
    1. Individuals & Interactions over processes & tools
    2. Working Software over comprehensive documentation
    3. Customer Collaboration over contract negotiation
    4. Responding to Change over following a plan
  • 12 supporting principles (short cycles, continuous delivery, reflection & adjustment)

Agile Propagated Fast

The Agile Manifesto website lists nearly 20,000 supporters from 2002 to 2016, when signatures stopped being accepted.

via Rebecca Koeser: https://us-rse.org/blog/2019/rsk/best-practices/

  • About half of these include email addresses, mostly commercial (.com). Notably, there are more signatories from various countries than .edu emails.

Agile & the Power of Language

  • The shift in language is arguably more important than the practices
  • Moving away from command-and-control terms:
    • “Resources” → “Team Members”
    • “Requirements” → “User Stories”
    • “Management Dictates” → “Collaboration” / “Self-Organization”

Why This Matters

  • Language shapes mindset and culture
  • Encourages empowered teams and continuous learning
  • Aligns with core Agile values and principles

Key Features of Agile

  • Time Box
  • Cross-Functional Team
  • A concrete "Thing that is DONE" at the end of each time box
    • Not an internal artifact that only the team can
      understand
    • A thing that could be shipped (maybe)

Agile in Practice – Scrum or Kanban

  • Scrum: fixed-length sprints (often 2 weeks), daily stand-ups, product owner roles.
  • Kanban: continuous flow, WIP (work in progress) limits, pull-based.
  • Either approach uses small increments + continuous user feedback.

(Optional) Show a quick Scrum board or Kanban board image.

User Stories

The Heart of Agile Requirements

“As a [user], I want [goal], so that [benefit].”

  • Shifts focus from system specs → user goals
  • Typically short, 1–2 sentences; capture what value is delivered
  • Encourages conversation with stakeholders
    • Facilitates exchanges in cross-functional teams

Why Do We Need User Stories?

  1. User-Centric: Keeps the user’s perspective front and center.
  2. Negotiable: They’re intentionally not super-detailed. Team + product owner can refine details in conversation.
  3. Testable: They must have clear acceptance criteria (we’ll see next!).
  4. Prevent Overengineering: If it’s not a real user need, it usually won’t appear as a user story.
  • INVEST is a checklist to ensure well-crafted user stories in Agile.
  • Coined by Bill Wake, it helps teams create user stories that are:

Making a Good User Story

Breakdown of INVEST

🔹 I - Independent

  • Each story should stand alone.
  • Avoid dependencies to allow flexible prioritization and parallel development.

🔹 N - Negotiable

  • Stories are not rigid contracts.
  • They should be open to discussion and refinement between the team and stakeholders.

🔹 V - Valuable

  • Stories must deliver value to the end user.
  • If a story doesn’t provide user benefit, reconsider its need.

🔹 E - Estimable

  • The team should be able to estimate effort.
  • If too vague, break it down or refine requirements.

🔹 S - Small

  • Keep stories manageable within a sprint.
  • Large stories should be split into smaller, independent ones.

🔹 T - Testable

  • Clear acceptance criteria should define when the story is "done."
  • If it can’t be tested, it’s not well-defined.

Why INVEST Matters

  • Ensures clarity and alignment in Agile teams.
  • Improves sprint planning and backlog refinement.
  • Helps avoid scope creep and keeps work deliverable.

Sample Good User Story

"As a user, I want to reset my password via email so that I can regain access to my account."
✅ Independent, valuable, and testable.
✅ Can be negotiated (e.g., method of password reset).
✅ Estimable and small enough for a sprint.

User Story

INVEST Quiz

Question 1:

❌ "As a user, I want a dashboard with all possible metrics so that I can track everything about my performance."

🔎 What's wrong?

✅ Better version: "As a user, I want to see my monthly sales metrics on a dashboard so that I can track my performance over time."

Answer:

  • Not Small (S): The story is too big and vague. What are "all possible metrics"? It should be broken into smaller, specific stories.
  • Not Estimable (E): The team can’t estimate effort without knowing what “everything” means.
  • Not Testable (T): No clear acceptance criteria—what defines "done"?

Question 2:

❌ "As a developer, I want to add an API for order processing."

🔎 What's wrong?

✅ Better version: "As a customer, I want my orders to be processed in real-time so that I receive confirmation immediately."

Answer:

  • Not Valuable (V): The story is written from a developer's perspective rather than the user's. What value does it provide to the end user?
  • Not Testable (T): No criteria to verify success—what should the API be able to do?

Question 3:

❌ "As a user, I want to receive email notifications when something changes in the system."

🔎 What's wrong?

✅ Better version: "As a user, I want to receive an email when my password is changed so that I can be alerted to security risks."

Answer:

  • Not Independent (I): What kind of changes trigger notifications? If it depends on another feature being built first, it’s not truly independent.
  • Not Testable (T): No way to define when it’s working correctly—what events should trigger the email?

Question 4:

❌ "As a user, I want the search function to be really fast."

🔎 What's wrong?

✅ Better version: "As a user, I want search results to load within 2 seconds so that I can quickly find what I need."

Answer:

  • Not Estimable (E): How fast is "really fast"? Without a performance target, it’s impossible to estimate.
  • Not Testable (T): No objective way to check if the story is completed.

Question 5:

❌ "As a user, I want to upload documents and share them with my team in multiple formats while integrating with Dropbox, Google Drive, and OneDrive."

🔎 What's wrong?

✅ Better version: "As a user, I want to upload documents so that I can store them securely in the system." (Other features can be separate stories.)

Answer:

  • Not Small (S): This story is too large—uploading, sharing, and integrating are separate features.
  • Not Independent (I): Integrations depend on third-party APIs, which may delay implementation.
Spec (System/Technical Requirement) Corresponding User Stories
Spec 1: The system must allow visitors to view health plan options before creating an account.

Rationale: To reduce friction for first-time users and encourage plan exploration.		 • Story 1: “As a first-time visitor, I want to browse available health plans without logging in, so that I can see my options before registering.”
• Story 2: “As a curious shopper, I want to see plan prices and coverage at a glance, so that I can quickly assess whether enrollment is worth my time.”
Spec 2: The system must support at least 2,000 concurrent users without significant performance degradation.

Rationale: Prevent site crashes under high demand (e.g., open enrollment).		 • Story 3: “As a returning user, I want the site to load within 2 seconds, so that I can quickly update my information during the busy enrollment period.”
• (Also ties in to multiple other user stories requiring fast response times under load.)
Spec 3: The system must comply with HIPAA regulations for protecting personal health information.

Rationale: Legal/regulatory compliance.		 • Story 4: “As a user, I want my personal data to remain confidential, so that I feel safe providing accurate health information.”
• Story 5: “As a security officer, I need to ensure all user data is encrypted at rest and in transit, so that we remain HIPAA-compliant.”
Spec 4: The user’s account creation process must incorporate identity verification steps (e.g., multi-factor authentication). • Story 6: “As a first-time applicant, I want to verify my identity securely, so that I can trust my account is protected and meets regulatory requirements.”
• Story 7: “As a user, I want optional two-factor authentication, so that I have extra security if I choose.”
Spec 5: The system must provide a robust error-handling mechanism, displaying clear user-friendly messages on failure. • Story 8: “As a user, if something goes wrong when submitting my enrollment, I want to see an error message that explains the next steps, so that I’m not stuck.”
• Story 9: “As a customer support rep, I want error logs to be easily traceable, so that I can quickly resolve user issues.”
Spec 6: The platform must store user plan selections and enrollment details to be retrieved later. • Story 10: “As an enrolled user, I want to review my chosen health plan details, so that I can verify my coverage anytime.”
• Story 11: “As a returning user, I want to pick up where I left off in my application, so that I don’t need to re-enter information.”

The Product Backlog

  • A Product Backlog is a prioritized list of all user stories (and sometimes epics, tasks, bugs) yet to be done.
  • Maintained by the Product Owner (or in smaller teams, collectively).
  • Always evolving: new stories get added, old ones get refined, priorities get reordered.

Epics vs. Stories vs. Tasks

Breaking Down Requirements

Level Description Example
Epic A large user need or objective, spans multiple sprints “Manage an on-campus food ordering and delivery system”
Story A small, specific user requirement that fits in 1 sprint “As a student, I want to add a meal to my Favorites, so I can reorder quickly”
Task Technical or smaller sub-step to implement part of a story “Create database table ‘Favorites’ with userId, mealId columns”

MVP

Minecraft is one of the most successful games in the history of game development, especially if you take development cost into consideration.

Minecraft is also one of the most extreme examples of the release-early-and-often mindset. The first public release was made after just 6 days of coding, by one guy ! You couldn’t do much in the first version – it was basically an ugly blocky 3d-landscape where you can dig up blocks and place them elsewhere to build crude structures.

Text

Acceptance Criteria & Acceptance Tests

  • Each story has Acceptance Criteria: bullet points that specify conditions of satisfaction.
  • Acceptance Tests are testable scenarios verifying the story works as intended.
    • Given [precondition], when [action], then [outcome]
  • If all acceptance criteria pass, the story is “Done.”

User Story with Acceptance Criteria

User story: “As a student, I want to favorite certain meal choices, so I can reorder them quickly.”
Acceptance Criteria (sample):

  1. A “Favorite” icon is visible next to each meal.
  2. Tapping the icon adds meal to my “Favorites.”
  3. Tapping again removes it.

Non-Functional Requirements & Constraints

  • Some requirements don’t fit neatly into user-stories. E.g.:
    • Performance: “System must support 2,000 concurrent users.”
    • Security/regulatory: “Must log all access for 7 years.”
    • Accessibility: “Must be screen-reader friendly.”
  • Often stored as separate backlog items or “Enabler” stories.

Example: Healthcare.gov Through an Agile Lens

Could user stories have prevented meltdown?

  • “As a first-time visitor, I want to browse plans without logging in, so I can see if this is worthwhile.”
  • “As a returning user, I want a quick login, so I can review my saved plan details.”
  • Acceptance Criteria would have discovered the forced-login choke point quickly.
  • Frequent demos + user feedback would reveal performance issues.

Zoom-in on SCRUM

One implementation of Agile methodology

Revisiting the Paper Airplane Challenge

This time with SCRUM!

Round 2 — Same Challenge, New Process

Key Points:

  • Same acceptance criteria (flies ≥2 meters, team name or logo).
  • Goal: Build as many acceptable airplanes in 7 minutes.
  • But this time: You’ll work with Scrum roles and timeboxes.

Scrum Roles & Timebox

Assign Roles (quickly within the team):

  1. Scrum Master – Facilitates, keeps everyone on track.
  2. Quality Control – Checks each plane against acceptance criteria.
  3. Builders – Everyone else folds or decorates.

Timebox Structure (example):

  1. Sprint Planning (1 minute)
    • Plan how many planes you’ll aim for, who does what.
  2. Building (3–4 minutes)
    • Produce airplanes, coordinate with QC, test mid-build if needed.
  3. Review & Retrospective (~1–2 minutes)
    • Quick flight test, count how many planes meet the criteria.
    • Discuss what worked (or didn’t).

JUDGING (2 mins)

  • One judge from
    • Table 1 -> goes to Table 10
    • Table 2 -> Table 1
    • Table 3 -> Table 2
    • ...
    • Table 10 -> Table 9
  • Judge must count valid planes
  • Judge must submit count on Sli.do
  • Judge will give count when called

Post-Round Debrief

Possible Discussion Questions:

  • What changed compared to Round 1?
  • Did having a Scrum Master or QC role improve coordination or quality?
  • How did timeboxing help (or not)?
  • Any lessons that map directly to real software projects?