Scrum Methodology — From Agile Foundations to Running Real Sprints
By the end of this module, you will be able to:
Everything up to now has been on paper. From this module onward you work inside Jira, the most widely used agile project tool in the industry. Before you start, make sure you can create a free Jira account (the free tier supports up to 10 users — more than enough for this course). Every later module builds on the Jira project you create today, so do not skip the hands-on sections.
Scrum is built on empiricism: decisions are made from what is observed, not what is assumed. But you can only inspect what you can see. Scrum's three artifacts exist for exactly one reason — to make the work and the value transparent so that everyone inspecting them sees the same reality:
An artifact that hides reality is worse than no artifact at all. A backlog nobody has updated in months, or an "increment" that only runs on one developer's laptop, gives the team false confidence and leads to bad decisions. Low-transparency artifacts are one of the most common ways Scrum quietly fails.
The 2020 Scrum Guide strengthened the artifacts by pairing each one with a commitment. The commitment answers the question: "against what do we measure progress on this artifact?" Without the commitment, the artifact is just a container; with it, the artifact has a direction.
| Artifact | Commitment | What the commitment provides |
|---|---|---|
| Product Backlog | Product Goal | A long-term objective for the product — the "destination" the backlog items step toward |
| Sprint Backlog | Sprint Goal | The single objective of the current Sprint — the reason the Sprint is worth running |
| Increment | Definition of Done | A shared quality standard — the formal description of the state work must reach to count as part of the Increment |
Think of each pair as map + destination. The Product Backlog is the map of everything we might do; the Product Goal is where we are heading. The Sprint Backlog is this leg of the journey; the Sprint Goal is why this leg matters. The Increment is the ground actually covered; the Definition of Done is the proof we really covered it and did not just draw a line on the map.
The Product Backlog is a single, ordered, emergent list of everything that might improve the product. Every word in that definition is load-bearing:
"Order by value" is the headline, but experienced Product Owners weigh at least four factors together:
How much does this item move users, revenue, or the Product Goal? The item a user cannot live without outranks the item that is merely nice. For TaskFlow, creating a task is worth more than dark mode — without the first, the second is pointless.
Items with big unknowns (a new technology, an unproven integration) may deserve to move up, so the team learns whether they are feasible while there is still time to change course. Deferring all risk to the end is the waterfall mistake all over again.
Some items technically require others. In TaskFlow, assigning a task to a teammate depends on sharing a project, which depends on having user accounts. Dependencies can force a lower-value item above a higher-value one.
Between two items of similar value, the smaller one often wins — it delivers feedback sooner and costs less if it turns out to be wrong. Size also signals when an item needs splitting before it can enter a Sprint.
Product Backlog refinement is the act of breaking down large items, adding detail, estimating, and re-ordering. Two things students often get wrong:
Roman Pichler and Mike Cohn's DEEP checklist is the standard health test for a Product Backlog:
| Quality | Meaning | Smell when it's missing |
|---|---|---|
| Detailed appropriately | Top items are Sprint-ready; lower items are intentionally coarse | Every item has 3 pages of spec — or the top item is a one-line mystery |
| Emergent | The backlog changes as learning arrives; items appear, split, and die | The backlog looks identical to three months ago |
| Estimated | Items carry a size (story points in this course, from Module 6) so ordering and forecasting are informed | Nobody can say whether the next release is two Sprints or ten away |
| Prioritised | Strictly ordered top to bottom, most valuable next work first | Forty items all marked "high priority" |
The Product Goal is the backlog's commitment: a single long-term objective that describes a future state of the product. The Product Backlog exists to serve it — every item should be a plausible step toward the goal, and items that serve no goal are candidates for deletion. The Scrum Team must fulfil (or abandon) one Product Goal before taking on the next; a team chasing three goals at once is really chasing none.
"Individuals can fully manage their daily tasks in TaskFlow."
Notice what it does not say: nothing about teams, sharing, dashboards, or dark mode. That is deliberate. A good Product Goal is narrow enough to be reached and to make ordering decisions for you: any story that helps a single user manage tasks outranks any story that does not — yet. When the goal is met, the team commits to the next one (perhaps: "Small teams can plan a week of work together in TaskFlow").
The Sprint Backlog is created at Sprint Planning (you will run one in Module 5) and is the Developers' plan for the Sprint. It is composed of three layers, often summarised as why, what, how:
Three rules govern the Sprint Backlog:
Changes during the Sprint must never endanger the Sprint Goal. Dropping a nice-to-have story to protect the goal is healthy adaptation; sneaking in an unrelated feature request from a loud stakeholder is a broken Sprint. The Sprint Goal is the test every mid-Sprint change must pass.
The Increment is the concrete output of a Sprint: a body of working product. Three properties define it:
The Definition of Done (DoD) is a formal, written description of the state work must reach to be considered part of the Increment. It is the team's shared quality bar. Its power is in what it removes: ambiguity. When a Developer says "the task story is done", everyone — PO, stakeholders, other Developers — knows exactly what that claim includes, because the DoD is written down and applies to every item equally.
Notice that every criterion is checkable — a yes/no question anyone can answer. "Code is clean" is an aspiration; "code is reviewed by another Developer" is a criterion. Also notice the DoD applies to every backlog item; per-item conditions ("the calendar shows overdue tasks in red") belong in that item's acceptance criteria, which you will meet properly in Module 6.
The Sprint ends on schedule regardless of the state of the work — the timebox is never extended. If an item does not meet the Definition of Done by the end of the Sprint:
An item is Done or it is not — Scrum recognises no partial credit. "90% done" software has a habit of staying 90% done for months, because the last 10% (integration, edge cases, testing) is where the risk lives. Counting almost-done work as progress destroys the transparency the Increment exists to provide. If a team consistently ends Sprints with half-done items, the fix is smaller stories and honest Sprint Planning — not a softer Definition of Done.
Time to leave the slides behind. In this lab you create a free Jira site and a Scrum project for TaskFlow. Work through the steps in order — the next lab and Modules 5–8 all build on this project.
yourname-scrum.atlassian.net. This is your team's home address in Jira.TF-1.TF-1 exists. You will create the remaining epics in the next lab.Jira predates the 2020 Scrum Guide and serves many methodologies, so its vocabulary does not match Scrum's word for word. Keep this mapping in mind:
You now have an empty project and a stakeholder wish list from Module 1. In this lab you convert that wish list into a real, ordered Product Backlog: four epics, at least twelve user stories, a deliberate order, and a written Product Goal.
Epics group related stories so the backlog stays navigable. Create these four (you already have the first):
The core loop: create, edit, complete, delete tasks; projects and lists; due dates, reminders, calendar.
Sharing projects, assigning tasks, comments, and attachments.
Google sign-in and user profiles — the foundation collaboration depends on.
Statistics dashboard, dark mode, mobile-friendly refinements.
Create each story below as an issue of type Story and assign it to its epic (drag it onto the epic, or set the epic in the issue's details panel). Type the titles exactly — we reuse them in Modules 5 and 6. The "As a … I can …" pattern is the user story format, which Module 6 dissects in depth; for now, treat it as a title convention that keeps the user in view.
# Epic: Task Management
As a user, I can create a task with a title and description
As a user, I can mark a task as complete
As a user, I can edit a task's title and description
As a user, I can delete a task
As a user, I can organise tasks into projects and lists
As a user, I can set a due date on a task
As a user, I can receive a reminder before a task is due
As a user, I can see my tasks in a calendar view
# Epic: Collaboration
As a project owner, I can share a project with a teammate
As a team member, I can assign a task to a teammate
As a team member, I can comment on a task
As a team member, I can attach a file to a task
# Epic: Accounts & Sign-in
As a visitor, I can sign in with my Google account
As a user, I can view and edit my profile
# Epic: Insights & Polish
As a user, I can switch to dark mode
As a user, I can view a statistics dashboard of my week
As a user, I can use TaskFlow comfortably on my phoneThat is 17 stories — comfortably past the 12 minimum. Feel free to add your own from Exercise 1.1, but keep these 17 intact.
In the Backlog view, drag the stories into a single top-to-bottom order. Here is a suggested top 10 with the reasoning — the reasoning matters more than the order itself, and your Module 4 Project asks you to defend your own:
| # | Story | Why here? |
|---|---|---|
| 1 | Create a task with a title and description | Highest value: without it there is no product at all |
| 2 | Mark a task as complete | Completes the smallest useful loop — add work, finish work |
| 3 | Edit a task's title and description | Users make typos immediately; core loop feels broken without it |
| 4 | Delete a task | Rounds out full task control — the Product Goal's word "fully" |
| 5 | Organise tasks into projects and lists | First big step beyond a flat list; high value for daily management |
| 6 | Set a due date on a task | "Daily tasks" implies time; unlocks reminders and calendar later |
| 7 | Sign in with my Google account | Moderate direct value but a dependency for all collaboration, and a risk item (external OAuth integration) worth de-risking early |
| 8 | Receive a reminder before a task is due | Builds directly on due dates; strong retention value |
| 9 | See my tasks in a calendar view | Valuable but larger; pure presentation on top of existing data |
| 10 | Share a project with a teammate | Opens the Collaboration epic once accounts exist — but note it serves the next Product Goal more than the current one |
Everything else — assignment, comments, attachments, dark mode, dashboard — sits below, deliberately coarse and unrefined. That is DEEP's "detailed appropriately" in action: we will refine those items only when they approach the top.
Write the Product Goal where the whole team will see it:
Product Goal: Individuals can fully manage their daily tasks in TaskFlow.Jira's team-managed projects have no dedicated "Product Goal" field, so use both of these conventions:
[PRODUCT GOAL] Individuals can fully manage their daily tasks in TaskFlow — some teams like the goal physically looking down at the list it governs. If you do this, never pull it into a sprint.Before moving on you should have: a Jira site, a team-managed Scrum project TaskFlow (TF), story points enabled, 4 epics, 17 ordered stories, and a recorded Product Goal. This exact project is the starting point of Module 5's Sprint Planning.
The example DoD earlier in this module is a starting point, not an answer key. Produce TaskFlow's own Definition of Done:
[DEFINITION OF DONE] at the top of the backlog — the same techniques you used for the Product Goal.A tempting student mistake is to write an aspirational DoD ("100% test coverage, zero known bugs, penetration tested") that no Sprint could ever satisfy. A Definition of Done the team cannot actually meet every Sprint produces permanent "not Done" work — which is worse than a modest DoD that is genuinely enforced and strengthened over time. Start realistic; ratchet up in Retrospectives.
| Component | Points |
|---|---|
| Jira project correctly set up (template, type, key, story points, sprints enabled) | 20 |
| Epics & stories complete, correctly grouped, and strictly ordered | 25 |
| Product Goal recorded and consistent with the backlog's top items | 10 |
| Definition of Done — 6+ checkable criteria, each defended | 25 |
| Top-5 ordering justification (correct use of value/risk/dependency/size) | 15 |
| Clarity and structure of the written submission | 5 |
| Total | 100 |