Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
TF) with 4 epics, 17 ordered stories, and a started two-week Sprint 1 with the goal "A user can manage a basic task list"In Module 5 the team planned Sprint 1 by feel: four stories looked achievable, so four were selected. That is exactly how new teams start — and it works for one Sprint. But "by feel" cannot answer the questions a Product Owner gets asked next: How much of the backlog fits in the next Sprint? When will the Collaboration epic ship? This module adds the missing arithmetic: well-formed stories, relative estimates, and velocity. By the end, every one of TaskFlow's 17 stories carries a number, and those numbers can forecast a release.
Work arrives big and gets built small. Between a stakeholder's wish ("teams should be able to work together") and a developer's Tuesday afternoon ("write the invite API endpoint") sit two or three levels of decomposition. Naming the levels precisely keeps the backlog navigable and the conversations honest:
POST /invites API endpoint with validationEach level answers a different question for a different audience:
| Level | Typical size | Lifespan | Primary audience | Answers the question |
|---|---|---|---|---|
| Epic | Multiple Sprints | Weeks to months | Stakeholders, PO | "Which big themes are we investing in?" |
| User story | Fits in one Sprint (ideally a few days) | Created in refinement, dies when Done | PO + Developers together | "What will a user be able to do next?" |
| Task / subtask | ≤ 1 day | Inside one Sprint | Developers | "What exactly do we do today?" |
Open the Scrum Guide and search for "epic", "story", or "subtask" — you will find nothing. Scrum only knows Product Backlog items. Epics, stories, and subtasks are popular conventions (baked into Jira) that most teams layer on top. Use them because they are useful, not because Scrum demands them — and never let a debate about "is this an epic or a story?" replace the real question: is this small enough to finish in a Sprint, and valuable enough to bother?
A user story is a short description of a capability told from the perspective of the person who wants it. The classic template — invented at the London company Connextra around 2001 — forces three pieces of information into one sentence:
As a <role>, I want <capability>, so that <benefit>.
# TaskFlow example
As a project owner, I want to invite a teammate by email,
so that we can manage our project's tasks together.Each clause earns its place. The role stops the team building for an imaginary "user" who is secretly the developer. The capability states the observable behaviour, not the implementation. The benefit is the most frequently skipped and the most valuable part: if you cannot finish the "so that…" clause convincingly, you have just discovered a backlog item that maybe should not exist. Your Module 4 backlog used the compact variant "As a …, I can …" as story titles — fine for titles; the full template with the benefit clause belongs in the story description.
Ron Jeffries' famous formula captures what a story is — and, more importantly, what it is not. A story is not a miniature requirements document; it is a promise to have a conversation:
The written token — an index card, or a Jira issue. Deliberately too small to hold every detail. The card's job is to be rememberable and sortable, not complete.
The details live in conversations between the PO and Developers — during refinement, Planning, and mid-Sprint. This is where "invite by email" gets its edge cases: expired invites? inviting someone twice?
The acceptance criteria — concrete tests that confirm the conversation was understood. Written down before the work starts, checked before the story is called Done.
Bill Wake's INVEST acronym is the standard quality gate for a story that is about to enter a Sprint. Run every candidate through all six letters — the TaskFlow examples below show each check failing and passing:
The story can be built and delivered in (almost) any order relative to its siblings.
Fails: "As a team member, I can assign a task to a teammate" scheduled before any sign-in or sharing exists — it silently depends on TF-17 and TF-13.
Passes: "As a user, I can set a due date on a task" — touches only the task model; can ship in any Sprint.
The story states the what, leaving the how open for the conversation.
Fails: "As a user, I can pick a due date from a jQuery datepicker widget in a modal dialog" — the solution is welded into the requirement.
Passes: "As a user, I can set a due date on a task" — calendar widget, text field, or natural-language parsing are all still on the table.
A user or stakeholder would notice — and care — if this shipped.
Fails: "As a developer, I want to refactor the task repository layer" — real work, but invisible to users; fold it into the stories that need it or justify it via the DoD.
Passes: "As a user, I can receive a reminder before a task is due" — retention gold; users will feel it.
The Developers know enough to size it relative to other stories.
Fails: "As a user, I want TaskFlow to feel fast" — fast how, where, measured by what? Unestimable until it becomes concrete criteria (e.g., task list loads in under 1 second on 3G).
Passes: "As a user, I can mark a task as complete" — everyone can picture the whole job.
Comfortably fits inside one Sprint — ideally a few days, leaving room for several stories per Sprint.
Fails: "As a user, I can organise tasks into projects and lists" (TF-9) — projects, lists, moving tasks, filtering, empty states… a Sprint-eater. It gets split later in this module.
Passes: "As a user, I can delete a task" — one endpoint, one button, one confirmation.
There is a concrete way to demonstrate it is done.
Fails: "As a user, I want the app to be intuitive" — no test can pass or fail this as written.
Passes: "As a visitor, I can sign in with my Google account" — click the button, complete the consent screen, land signed-in. Pass or fail.
Items deep in the backlog are allowed to fail INVEST — DEEP (Module 4) told you distant items stay deliberately coarse. INVEST applies with full force only to stories about to enter a Sprint. A story failing "Small" is not deleted; it is split. A story failing "Estimable" earns a conversation or a research spike. The checklist tells you what kind of refinement an item still needs.
Acceptance criteria (AC) are the third C made concrete: the per-story conditions that must hold before the Product Owner accepts the work. They turn "I thought you meant…" arguments into a checklist agreed before coding starts. The most popular format is Given/When/Then — the Gherkin syntax from behaviour-driven development — which reads: given a starting context, when an action happens, then an observable outcome follows.
Here is a full set for the story your Sprint 1 anchors on, TF-5: As a user, I can create a task with a title and description:
Story: As a user, I can create a task with a title and description
Scenario 1: Create a task with valid input
Given I am signed in and viewing my task list
When I enter the title "Buy milk" and the description "2 litres, semi-skimmed"
and press "Add task"
Then the task appears at the top of my list with its title visible
And the input form is cleared, ready for the next task
Scenario 2: Title is required
Given I am signed in and viewing my task list
When I press "Add task" with an empty title
Then no task is created
And I see the message "A task needs a title"
Scenario 3: Description is optional
Given I am signed in and viewing my task list
When I enter only the title "Call the dentist" and press "Add task"
Then the task is created with an empty description
Scenario 4: Title length is bounded
Given I am signed in and viewing my task list
When I enter a title longer than 200 characters
Then no task is created
And I see the message "Titles are limited to 200 characters"Notice what the four scenarios just did: they surfaced a validation rule (title required), a product decision (description optional), and a boundary (200 characters) that the one-line story never mentioned. Writing AC is the conversation, captured.
Given/When/Then shines for behaviour with clear flows, but it gets ceremonious for simple constraints. Many teams use a plain rule checklist instead — or mix both. The same story as rules:
Jira has no dedicated AC field in team-managed projects, so adopt one convention and stick to it — consistency matters more than the choice:
Both are checklists; they answer different questions. Acceptance criteria are per-story: "does this story do what we agreed?" ("titles are limited to 200 characters"). The Definition of Done is universal: "does every story meet our quality bar?" (code reviewed, tests green, deployed to staging, responsive, accessible — the DoD you wrote in Module 4). A story is finished only when it satisfies both. If you find yourself copying "code is reviewed" into every story's AC, that line belongs in the DoD; if your DoD says "the calendar shows overdue tasks in red", that line belongs in one story's AC.
Big stories are where Sprints go to die: they burn no points for days, hide unknown work, and turn the burndown into a cliff. The fix is splitting — but splitting correctly. Every slice must remain a vertical slice: a thin path through UI, logic, and data that a user could actually exercise. Five patterns cover most situations; each row shows the pattern applied to a real TaskFlow story:
| Pattern | How it works | TaskFlow example |
|---|---|---|
| By workflow step | The story describes a multi-step journey; each step becomes a story, earliest steps first. | TF-13 invite a teammate → ① send an invitation email → ② accept an invitation and join the project → ③ view and revoke pending invitations. |
| By CRUD operation | "Manage X" always hides create, read, update, delete — four stories wearing a trench coat. | TF-9 organise tasks into projects → ① create a project and add tasks to it → ② rename a project → ③ archive/delete a project → ④ move a task between projects. |
| By role | Different roles need different depth; ship the most valuable role's version first. | TF-20 statistics dashboard → ① as an individual user, my personal weekly stats → ② as a project owner, aggregated stats for the whole team. |
| Happy path first | Deliver the main success flow; edge cases, errors, and hardening become follow-up stories. | TF-17 sign in with Google → ① successful sign-in for a new user → ② handle declined consent, expired sessions, and linking an existing email to a Google account. |
| By data variation | Support the simplest data shape or channel first; each additional variation is its own story. | TF-11 reminders → ① email reminder 24 h before the due date → ② in-app/browser notification → ③ user-configurable reminder timing. |
Two quality checks after any split. First, every slice must still pass INVEST — especially Valuable: "create a project" is demonstrable to a stakeholder; "build the projects database table" is not. Second, expect the slices' estimates to sum to more than the original story's estimate. That is not waste — the original number was hiding uncertainty, and the split just made the real cost visible.
The tempting wrong split is by technical layer: "the API story", "the database story", "the UI story". Now nothing is demonstrable until all layers land, dependencies chain the Sprint together, and the Review has nothing to show. If a slice cannot be clicked through by a user (or at least demonstrated end-to-end), it is a task inside a story — not a story.
Now the second half of the module: putting numbers on stories. The instinctive unit is hours — and hours fail in practice, for reasons every experienced team rediscovers:
The escape is relative estimation: people who cannot say how tall a building is in metres can instantly say it is about twice as tall as the one next to it. Story points are unitless numbers expressing how big a story is compared to other stories — a blend of effort, complexity, and uncertainty. A 4-point story is roughly twice the work of a 2. Points mean nothing outside the team that assigned them, and that is by design.
Most teams estimate on a modified Fibonacci sequence: 1, 2, 3, 5, 8, 13 (some add 20, 40, and 100 for epic-sized guesses). The growing gaps are the entire point: uncertainty grows with size. You can meaningfully debate whether a small story is a 2 or a 3 — but debating whether a big story is an 8 or a 9 is theatre, because nobody's crystal ball is that good. The scale physically prevents false precision: after 8, your only options are "13" or "split it".
| Points | Feels like | TaskFlow example |
|---|---|---|
| 1 | Trivial, well-understood, nearly risk-free | Delete a task (TF-8) |
| 2 | Small and clear — the reference size | Create a task with title and description (TF-5) |
| 3 | Moderate; a couple of moving parts | Edit a task's title and description (TF-7) — inline editing and stale-data handling add wrinkles |
| 5 | Large; several components or a real unknown | Sign in with Google (TF-17) — external OAuth integration |
| 8 | Very large; should make you nervous | Organise tasks into projects and lists (TF-9) |
| 13 | Too big to Sprint — split before selecting | A hypothetical "full team workspace" story |
Relative measurement needs an anchor. Pick one story the whole team understands completely, pin its value, and estimate everything else by comparison. Our anchor for the rest of the course:
# TaskFlow reference story (the anchor)
TF-5 "As a user, I can create a task with a title and description" = 2 pointsEvery estimation conversation now has a shape: "Is editing a task bigger or smaller than creating one? About the same, plus wrinkles → 3. Is Google sign-in bigger? Clearly — twice? more? → 5." Strong teams triangulate against two anchors (one small, one large) so every story is squeezed from both sides. One nuance from Module 5: in Sprint 1, TF-5's subtasks included one-off repository and CI setup — that made the story's first implementation slow, but the anchor reflects the feature's inherent size, not the historical accident of which story paid the setup tax.
Not hours in disguise. The moment someone publishes a "1 point = 4 hours" conversion table, you have hour estimates with extra steps — and all their pathologies back. Not a performance metric. Comparing developers by points completed, or teams by velocity, is measuring with rulers of different lengths — and the instant points affect anyone's appraisal, estimates inflate and the metric destroys itself. Not a commitment. An estimate is information, not a contract; punishing "wrong" estimates teaches people to stop estimating honestly. Points serve exactly one master: the team's own planning. Guard that boundary fiercely.
Planning Poker is the standard way teams produce point estimates together. It looks like a game; it is actually a defence mechanism against anchoring — the human tendency to gravitate toward the first number spoken aloud. If the most senior developer says "3" first, everyone's honest "8" quietly becomes "5". Simultaneous reveal removes that distortion. A round works like this:
Tools: physical card decks work great in a room; distributed teams use free web tools — planningpoker.com, PlanITpoker, or a Planning Poker app from the Jira Marketplace that runs inside the backlog view. Zero-budget fallback: everyone types a number into the chat and presses Enter on a count of three.
Rania (PO) reads the story and its AC: send an email invitation, the recipient clicks a link, joins the project. Questions land: can you invite someone without a TaskFlow account? (Yes — the invite link takes them through sign-up.) Do invites expire? (Yes, after 7 days.)
Reveal: Sara 3 · Lina 2 · Omar 8
Lina (low, 2): "It's a form, an endpoint, and a membership row — barely bigger than creating a task."
Omar (high, 8): "The form is the easy part. We have never sent an email from TaskFlow. There is no email provider configured, no templates, no handling for bounces or spam-folder deliverability — and the accept link has to work for people with no account yet. That's infrastructure, not a form."
Silence, then nodding — nobody else had thought about the email plumbing. Rania confirms the invitation email is essential to the story, not optional polish.
Re-vote: Sara 5 · Lina 5 · Omar 5 → TF-13 = 5 points. Lina came up from 2, Omar came down from 8 (the team agreed a basic email-provider setup is a known quantity), and the discussion left a comment on the ticket about the email work — which will save whichever Sprint eventually pulls it.
Watch what actually happened in that round: the estimate moved from a 2–8 spread to 5, but the real output was the discovery of hidden email infrastructure work — before the Sprint, while it was still cheap to know. Teams that skip the outlier discussion and just average the cards keep the ritual and throw away the value. If your poker sessions produce numbers but never surprises, you are running them too fast.
Velocity is the number of story points a team gets to Done per Sprint — and "Done" means the full Definition of Done, because Scrum gives no partial credit (Module 4). If Sprint 1 finishes 12 points of stories, velocity is 12. One data point is noise; after about three Sprints, the rolling 3-Sprint average becomes a genuinely useful forecasting tool — an empirical measurement of this team's real, sustainable pace, with meetings, code review, and bad Tuesdays already priced in.
Once the backlog is estimated, forecasting is division. TaskFlow's 17 stories total 60 points (you will produce this number in the lab below). Suppose velocity settles at 15 points per Sprint:
| Sprint | Points completed (forecast) | Backlog remaining after | Milestone reached |
|---|---|---|---|
| Sprint 1 | 15 | 45 | Core task loop: create, complete, edit, delete + sign-in |
| Sprint 2 | 15 | 30 | Projects, lists, and due dates |
| Sprint 3 | 15 | 15 | Reminders, calendar, first collaboration stories |
| Sprint 4 | 15 | 0 | Collaboration complete + insights & polish |
60 ÷ 15 = ~4 Sprints ≈ 8 weeks to the whole wish list. Present forecasts honestly: as a range, not a date — "3 to 5 Sprints, tightening as velocity stabilises". And remember the backlog is alive: every Review adds items, so the finish line moves. Velocity forecasts capacity, not destiny.
Velocity looks across Sprints; the burndown chart looks inside one. Vertical axis: story points remaining in the Sprint. Horizontal axis: Sprint days. A straight ideal line descends evenly from the committed total to zero; the actual line shows reality — and reality burns in steps, because points only leave the chart when a whole story reaches Done:
Ideal (grey) descends 2 points per day: 18, 16, 14 … 0. Actual (blue) plateaus at 20 for two days (nothing Done yet), steps down as whole stories finish — and notice day 6 sitting above day 5: a story was added mid-Sprint. Real burndowns are staircases with a story, not smooth slopes.
| Shape | What it looks like | What it usually means | Response |
|---|---|---|---|
| Flat line | Actual stays horizontal for days | Stories too big to finish (nothing reaches Done), work blocked, or the team is "90% done" on everything at once | One flat day is normal; two or more means raise it at the Daily — swarm, unblock, or split |
| Cliff at the end | Flat all Sprint, then everything drops on the last day | Stories moved to Done in a batch — oversized items, or the DoD applied only at the deadline; risk was invisible for two weeks | Smaller stories; finish items continuously, not in a day-10 crunch |
| Scope-added bump | The line jumps up mid-Sprint | Work was added after the start — a renegotiation with the PO (legitimate) or scope leaking in sideways (not) | Ask who added it and whether the Sprint Goal is still safe; Jira marks these as scope changes |
| Below ideal early | Actual hugs zero by mid-Sprint | The team under-committed — or quality is being skipped | Pull the next backlog item in collaboration with the PO; check the DoD is really being met |
The chart's job is to trigger a conversation while there is still time to act — "at this rate, TF-17 won't make it; what do we change today?" The moment a manager uses burndowns to grade teams, teams learn to make the chart pretty instead of the product good. You will read a real burndown, plateau and all, in Module 7's simulation.
Time to put numbers on all 17 stories in your Jira project. Sprint 1 is already running — that is fine: estimation is a refinement activity and happens whenever the team needs it. Work through the steps in order:
TF-5 — As a user, I can create a task with a title and description and set Story point estimate = 2. Add a comment: Reference story — all other estimates are relative to this = 2. Every future debate now has an anchor.
| Key | Story | Epic | Points |
|---|---|---|---|
| TF-5 | Create a task with a title and description (anchor) | Task Management | 2 |
| TF-6 | Mark a task as complete | Task Management | 2 |
| TF-7 | Edit a task's title and description | Task Management | 3 |
| TF-8 | Delete a task | Task Management | 1 |
| TF-9 | Organise tasks into projects and lists | Task Management | 8 |
| TF-10 | Set a due date on a task | Task Management | 2 |
| TF-11 | Receive a reminder before a task is due | Task Management | 5 |
| TF-12 | See my tasks in a calendar view | Task Management | 5 |
| TF-13 | Share a project with a teammate (invite by email) | Collaboration | 5 |
| TF-14 | Assign a task to a teammate | Collaboration | 3 |
| TF-15 | Comment on a task | Collaboration | 2 |
| TF-16 | Attach a file to a task | Collaboration | 3 |
| TF-17 | Sign in with my Google account | Accounts & Sign-in | 5 |
| TF-18 | View and edit my profile | Accounts & Sign-in | 2 |
| TF-19 | Switch to dark mode | Insights & Polish | 2 |
| TF-20 | View a statistics dashboard of my week | Insights & Polish | 8 |
| TF-21 | Use TaskFlow comfortably on my phone | Insights & Polish | 2 |
| Total backlog | 60 |
TF-17 — Sign in with my Google account (5 points) into the running Sprint: it strengthens the goal (a personal task list needs an account) and de-risks the OAuth integration the Module 4 ordering flagged. Drag TF-17 from the backlog into the active sprint and confirm. New committed total: 13 points.
Yes, done this way. The Scrum Guide is explicit: as new work is learned about, the Developers negotiate the scope of the Sprint Backlog with the Product Owner — without endangering the Sprint Goal. That is exactly what happened here: the people doing the work found spare capacity and pulled the next goal-supporting item, in collaboration with the PO. What is not allowed is scope arriving from outside — a stakeholder pushing work in over the team's head. Hold onto that distinction: in Module 7, Day 4, someone will test it.
Before continuing you should have: all 17 stories carrying story points (total 60), TF-5 documented as the 2-point anchor, Sprint 1 committed at 13 points across five stories (TF-17 included), and the burndown report located and understood. This exact state is where Module 7's day-by-day simulation begins.
The Insights & Polish epic is the thinnest in the backlog — three stories, all coarse. Invent three new user stories for it (ideas: a weekly email summary, productivity streaks, exporting tasks to CSV, a focus mode, per-project colour themes — or your own). For each story:
TF-20 — As a user, I can view a statistics dashboard of my week is an 8 — tied for biggest story in the backlog and a poor fit for any Sprint. Split it twice, using two different patterns from the Splitting section (e.g., once by role, once happy-path-first or by data variation):
You are the team's estimation facilitator. Your deliverable is a TaskFlow backlog a Product Owner could genuinely plan releases from — every item sized, the sizing defensible, and a first release forecast on paper.
| Component | Points |
|---|---|
| Backlog fully estimated in Jira — Fibonacci values, anchor documented, sprint total correct | 20 |
| Estimation rationales — genuinely relative reasoning, not disguised hours | 15 |
| Exercise 6.1 — story quality (Connextra + INVEST) and testable Given/When/Then criteria | 25 |
| Exercise 6.2 — two valid patterns, vertical slices, thoughtful comparison | 15 |
| Release plan — arithmetic correct, ordering respected, forecast as a range, honest assumptions | 20 |
| Clarity and structure of the written submission | 5 |
| Total | 100 |