310 Q1 UserStory

Acceptance gate

DoD is the shared contract for sign-off between devs and product owner.

Agile board (Kanban)

Visual board with Product Backlog, WIP limits, and pull-based flow.

Agile context

User stories are widely used within agile methodologies to structure work.

Agile tie-in (broken code)

Maps to working software, responding to change, and individuals & interactions.

Anti-pattern: giant story

High risk of missing iteration; split to reduce uncertainty.

Anti-pattern: no DoD

Leads to scope creep and unverifiable completion.

Anti-pattern: solution masquerading as story

E.g., ‘Build React page’ without user value.

Anti-pattern: vague notes

Notes that restate the role/goal add no scoping value.

Avoid solution bias

State the user problem and value before naming technologies.

Bad story: ‘Add extra tests’

No user, no value, no acceptance criteria.

Bad story: ‘Design team creation interface’

Describes a design task, not user value; not a user story.

Bad story: ‘Implement TeamCreator’

Unclear; solution-oriented; lacks user, value, and DoD.

Benefits of small stories

Clear DoD, quicker failure detection, legal traceability, easy work distribution.

Broken code: 3 rules

1) Does its job (no bugs) 2) Affords change 3) Understandable to others/future you.

Code review checklist

Design, functionality, complexity, tests, naming, comments, style, documentation.

Code review—author step

Open PR; self-review; choose reviewers; give context and rationale.

Cohesion benefit

Stories increase cohesion between customer/product owner and the development team.

Comment severity levels

Nit (minor), Optional/Consider (non-blocking), FYI (future idea/awareness).

Concrete example — Role/Goal/Benefit

As a prof, I want to create repositories so students can do their work.

Consistent terminology

Use the same stakeholder and domain terms across stories.

Continuous improvement

Refine INVEST and DoD quality in retrospectives.

Core template

As a , I want so that .

Cross-team constraints

Document interfaces and contracts in engineering notes.

Customer understanding via stories

Gives customers a concrete view of what the team will build for a feature.

Data for trade-offs

Stories return cost/value data so customers can weigh trade-offs across features.

Definition of Done (DoD)

Concrete, verifiable conditions that prove the story is complete and correct.

Definition of Done ties to validation

DoD specifies exactly how the customer will validate done/complete/correct.

Definition reminder

User stories describe features; they are not requirements specs or designs.

Dependency handling

Prefer independent stories; if blocked, note prerequisites explicitly.

E — Estimatable

Has enough detail to judge feasibility and effort.

Edge cases in notes

Document non-happy paths to bound scope and testing.

Effort estimate as value lens

Makes cost explicit so value vs. cost conversations are concrete.

Effort estimate attachment

Attach hours or points to help planning and prioritization.

Example — DoD (automated tests)

Provide automated test cases; the feature is programmatically verifiable.

Example — DoD (single command)

Feature runs as a single command with required parameters.

Effort estimate as value lens

Makes cost explicit so value vs. cost conversations are concrete.

Effort estimate attachment

Attach hours or points to help planning and prioritization.

Engineering notes purpose

List integrations, constraints, interactions with other parts, domain knowledge needed.

Engineering tasks vs stories

Tasks are dev-facing steps (e.g., set up DB); not phrased as user value.

Engineering tasks/notes purpose

Record interactions with other features/subsystems and technical considerations.

Estimating story points (simple table)

Use structured categories (e.g., simple/complex × single/multiple locations).

Example DoD — CLI

Single command accepts params and completes the task.

Example DoD — Integration test

Ensures compatibility with the GitHub API.

Example DoD — Script tests

Provide scripts for command-line aspects.

Example DoD — Unit tests

Errors covered for org, team name, and members.

Example DoD — Verifiability

Success is programmatically verifiable.

Example Engineering note — Config

Changeable constants live in config.js.

Example Engineering note — Future UI

API will be used by a future UI; design accordingly.

Example Engineering note — Integration

Must integrate with existing GitHubManager.

Example — Benefit

So the team can start working on the project.

Example — DoD (automated tests)

Provide automated test cases; the feature is programmatically verifiable.

Example — Estimate

Estimate: 1.5 units (per team’s scale).

Example — Notes

Inputs: team name, initial repo, team member GitHub IDs.

Example — Notes specifics

Inputs: list of repository names and list of student IDs (GitHub usernames).

Example — Role/Goal

As a prof, I want to create a repository for a 310 team.

Feature value vs cost decisions

Explicit costs enable deferring low-value, high-cost features to later.

Fibonacci for points

Use 1,2,3,5,8,… because estimation uncertainty grows with size.

Five parts overview

(1) Role–Goal–Benefit, (2) Limitations/Clarifications, (3) Definition of Done, (4) Engineering tasks/notes, (5) Effort estimate.

How to split big stories

Slice by workflow step, happy path vs. edge cases, or data subset.

I — Independent

Story can be reordered and implemented without tight coupling.

Independent ? unsequenced

Within one sprint, stories shouldn’t block each other even if long-term they build up.

INVEST: Estimable action

If not estimable, add details, split the story, or run a spike until it is.

INVEST: Estimatable nuance

Story must be precise enough to timebox; vague = risk of overruns.

INVEST: Independence nuance

Avoid precedence chains so teams can freely select stories from the backlog.

INVEST: Independent nuance

Independent to prioritize freely, but can still be sequenced across sprints.

INVEST: Negotiable details

Client-friendly language + time estimates enable real trade-offs.

INVEST: Negotiable nuance

Stories are living documents; negotiation often adds scope detail during planning.

INVEST: Small advantages

Smaller stories are easier to estimate, reason about, negotiate, and decouple.

INVEST: Small nuance

Sized to fit a sprint; too tiny can cause new dependencies—aim for balance.

INVEST: Testable link

Testability flows from a clear DoD agreed by customer and developer.

INVEST: Testable nuance

Define how to test and what pass criteria mean; avoid vague goals like 'make user happy'.

INVEST: Valuable nuance

Frame refactors in terms of customer value; exceptions exist but are rare.

INVEST: Value over time

Re-evaluate feature value as product/customer needs evolve before pulling it in.

INVEST acronym

Independent, Negotiable, Valuable, Estimatable, Small, Testable.

INVEST walkthrough context

Company email system with a contacts DB.

INVEST walkthrough user story

As an employee, search contacts by name to message them.

Iteration size constraint

Each story’s cost must fit within a single iteration (e.g., a ~2-week Scrum sprint).

Limitations/Clarifications purpose

Scopes the story to the subset of situations that matter; reduces ambiguity.

Link DoD to tests

Acceptance criteria should map to automated and/or scriptable checks.

Local estimation scale

1,2,3,5,8 with shared team definitions for each size.

N — Negotiable

Scope/details can be adjusted via conversation during planning.

Negotiation outcome

Capture agreed scope changes in notes and DoD immediately.

Points vs hours

Some teams avoid hours; others map points roughly to developer-hours.

Pre-release validation

Use DoD as checklist for demos and release readiness.

Prioritization signal

Value statement helps product owner rank stories.

Problem vs. Solution domain

Role–Goal–Benefit + DoD are problem-domain; engineering notes are solution-domain.

Reordering flexibility

Independent stories allow reprioritization between iterations.

Role–Goal–Benefit meaning

Who it’s for, what it does, and why it matters.

Role–Goal–Benefit purpose

Forces clarity on who benefits, what they’re trying to achieve, and why (value).

S — Small

Should take about half a day to half an iteration; split if larger.

Schedule slip rationale

Doubling a 2-week sprint is manageable; doubling a 1-year feature devastates schedules.

Stories as feedback vehicles

Because they’re small, they support quick customer feedback and iteration.

Stories drive backlog selection

Clear role/value and cost help prioritize which stories enter the next sprint.

Story points inform hours

Points help infer hours and prioritize stories for a sprint.

Story readiness checklist

Has role/goal/benefit, key notes, DoD, and a preliminary estimate.

Story ‘small & valuable’ summary

This example is small, clearly valuable, testable, and costed, fitting INVEST.

Subsystem interaction awareness

Engineering notes ensure cross-feature and subsystem impacts are captured.

T — Testable

Clear DoD enables objective verification.

Test review specifics

Are tests present, correct, at right level, and failing when they should?

Testable vs not testable

“Select x items in y seconds” is testable; “make user happy” isn’t.