Scrum: a 60-day reading companion

How to use this track

This is a reading companion for learning Scrum over 60 days. Read the assigned section in your own book, then use the corresponding article to connect it to a concrete software development decision. The examples and reflection questions here are original; the books supply the longer explanations.

All sixty companion articles are available above. The reading sequence below links each day to its article and book assignment. Follow it in order or return to the topic that supports your current question.

Start with a ten-minute reading session each morning. A companion and its book section may take longer together: pause at a natural stopping point and continue the next morning. The day numbers express an order, so missing a morning does not mean skipping a topic. The plan selects and revisits material; it does not require finishing every page of all three books within two months.

The recurring example is ShiftSwap, a fictional product that helps café employees exchange shifts. Its users, conversations, numbers, and decisions are invented for this series. They give us a consistent setting for discussing what we would do and what evidence we would need.

The reading shelf

• PG: Gunther Verheyen, Scrum: A Pocket Guide, fourth edition (2024). Section numbers below refer to this edition. The publisher's sample contains its table of contents.
• MPS: Stephanie Ockerman and Simon Reindl, Mastering Professional Scrum, first edition, published in 2019. Its publisher lists the chapter and subsection headings used to locate the readings.
• S30: Ken Schwaber and Jeff Sutherland, Software in 30 Days, 2012. Use the chapter numbers below; focus on the day's question when a chapter is longer than your reading window.
• SG: Ken Schwaber and Jeff Sutherland, the official Scrum Guide, November 2020. Keep this open as the reference for the framework. The two older books predate this version, so check older terminology and descriptions against it.

For PG, a section number identifies an exact reading. For MPS and S30, chapter numbers locate a reading and the topic after the semicolon tells you where to focus. These are reading assignments and original learning objectives, not chapter summaries. Optional techniques in the books should be evaluated in their context; the Scrum Guide supplies the framework's requirements.

Days 1–10: build a useful mental model

Day	Topic and objective	Reading
01	When a good plan meets real users: distinguish an observation from an assumption.	PG §1.1; SG definition
02	Agile values in everyday decisions: explain a trade-off using a value.	PG §§1.2–1.3; Agile Manifesto
03	Build something usable, then learn: distinguish adding capability from improving it.	PG §1.4; SG Increment
04	Planning under uncertainty: identify a decision worth delaying and one worth making now.	PG §1.5
05	Where the work waits: trace where a small change spends its time.	PG §1.6
06	Evidence that changes the plan: describe what would cause a team to change its plan.	PG §2.6; SG theory
07	How the framework fits together: connect its parts to a product decision.	PG §§2.1–2.4; SG overview
08	Values when the news is uncomfortable: choose a response to an uncomfortable conversation.	PG §2.7; SG values
09	A team that can finish: identify a dependency that prevents delivery.	PG §2.5, team discussion; SG Scrum Team
10	A Product Goal that guides decisions: describe an outcome that can guide several Sprints.	SG Product Goal; PG §2.5, product discussion

Days 11–20: follow one Sprint

Day	Topic and objective	Reading
11	Product Owner decisions: distinguish accountability from doing every task.	SG Product Owner; PG §2.5
12	Developers own the delivery plan: explain who chooses how to build and how to adapt the work.	SG Developers; PG §2.5
13	Helping the team become more effective: identify a useful Scrum Master intervention that supports the team.	SG Scrum Master; PG §2.5
14	What can change during a Sprint: decide what can change while a Sprint is running.	SG Sprint; PG §3.7
15	Planning toward a Sprint Goal: connect purpose, selected work, and the delivery plan.	SG Sprint Planning; PG §2.5
16	A Daily Scrum that changes the plan: choose the adjustment the Developers need to make.	SG Daily Scrum; PG §3.2
17	A Review that informs the next decision: turn stakeholder feedback into a possible next step.	SG Sprint Review; PG §2.5
18	A Retrospective with an experiment: propose one change the team can evaluate.	SG Sprint Retrospective; PG §2.5
19	Making progress visible: connect each artifact with its commitment.	SG artifacts; PG §3.1
20	Choosing practices for a purpose: separate a useful practice from a Scrum requirement.	PG §§3.3–3.6, selected examples

Days 21–30: create the conditions for delivery

Day	Topic and objective	Reading
21	Assessing today's practice: identify one problem worth improving.	MPS ch. 1; improvement areas
22	A small improvement experiment: define a change and the evidence to inspect.	MPS ch. 1; improvement process
23	Shared team purpose: explain what the team is collectively trying to achieve.	MPS ch. 2; identity and membership
24	Working agreements: turn a recurring disagreement into an observable agreement.	MPS ch. 2; working agreements
25	Ownership of the work: identify a decision the team should make together.	MPS ch. 2; self-organization, alongside SG self-management
26	Collaboration across skills: redesign a handoff that regularly delays delivery.	MPS ch. 2; collaboration and development
27	A shared quality boundary: make an ambiguous completion claim testable.	MPS ch. 3; Definition of Done; SG Definition of Done
28	Keeping a Sprint coherent: explain how a goal helps with a scope trade-off.	MPS ch. 3; Sprint Goals
29	Finishing sooner: find an opportunity to complete one small piece end to end.	MPS ch. 3; finishing items earlier
30	Too much started work: choose what to stop starting so something can finish.	MPS ch. 3; work in progress

Days 31–40: quality, value, and planning

Day	Topic and objective	Reading
31	Quality throughout delivery: identify a late check that could inform work earlier.	MPS ch. 3; quality practices and measures
32	Technical debt as a product decision: explain a trade-off in terms of future choices.	MPS ch. 3; technical debt
33	Defining useful results: separate shipping a feature from helping a user.	MPS ch. 4; value and delivery speed
34	Connecting work to purpose: link a small product change to a larger ambition.	MPS ch. 4; product vision and team purpose
35	Choosing evidence of value: propose a measure and explain its limitations.	MPS ch. 4; value measurement
36	Listening to conflicting feedback: decide what to investigate next.	MPS ch. 4; feedback and adaptation
37	Planning across different horizons: distinguish a direction from a detailed near-term plan.	MPS ch. 5; product mindset and alignment
38	Making work understandable: identify the conversation an unclear item needs.	MPS ch. 5; refinement; PG §3.3
39	Selecting work for a Sprint: reason about capacity, a goal, and uncertainty together.	MPS ch. 5; Sprint planning; SG Sprint Planning
40	Forecasts and promises: explain what a release forecast depends on.	MPS ch. 5; refinement horizon and release planning

Days 41–50: improve the team and its environment

Day	Topic and objective	Reading
41	A retrospective that leads somewhere: turn a complaint into an improvement to try.	MPS ch. 6; retrospectives
42	Finding an impediment's owner: identify who can change a recurring obstacle.	MPS ch. 6; impediments
43	Growing capability: propose a learning investment that reduces a team dependency.	MPS ch. 6; individual and team growth
44	Scrum Master effectiveness: connect an intervention to the team's ability to improve.	MPS ch. 6; Scrum Master accountability
45	Organizational constraints: explain why a local improvement might need wider support.	MPS ch. 7; organizational evolution and people
46	Discussing bad news: describe a response that makes useful information easier to share.	MPS ch. 7; transparency and accountability
47	Managing constraints honestly: describe what can change when time or money is limited.	MPS ch. 7; control, constraints, and funding
48	Expanding responsibly: identify what should improve before adding more teams.	MPS ch. 7; outcomes and scaling; PG §3.8
49	Taking stock: compare your initial assumptions with your understanding now.	MPS ch. 8 and appendix A, selected prompts
50	Checking misconceptions: explain one familiar claim using the current framework.	MPS appendix B; SG

Days 51–60: connect the practice to organizational choices

Day	Topic and objective	Reading
51	Recognizing an unsuitable approach: identify where a delivery plan assumes too much certainty.	S30 ch. 1
52	Evaluating the case for Scrum: identify both an expected benefit and evidence needed to assess it.	S30 ch. 2
53	Designing a useful pilot: choose a bounded initiative with a clear learning question.	S30 ch. 3
54	Sponsoring change: identify a concrete decision a manager can make to help.	S30 ch. 4
55	Supporting an actual team: connect organizational intentions to the conditions for delivery.	S30 chs. 5–6, selected passages; SG Scrum Team
56	Building lasting capability: identify what must remain after an initial pilot ends.	S30 ch. 7, selected passages
57	Moving beyond one team: investigate a structural obstacle to wider adoption.	S30 chs. 8–9, selected passages; PG §4.2
58	Inspecting the change itself: define a feedback loop for an adoption effort.	S30 ch. 10
59	Reconciling the books: separate current rules, older terminology, and contextual advice.	SG; revisit marked passages from all three books
60	Choosing your next experiment: propose a practical change and a date to inspect its results.	PG §4.1; MPS ch. 8; optional Scrum Open assessment

Keep a small reading log

After each session, record the day number, the section you actually read, one idea you can explain in your own words, and one question that remains. Revisit an earlier entry occasionally and revise it when your understanding changes.

For the morning reminder, use the day number and the article's permanent URL. Progress should follow the last reading you completed. The reference for this sequence is /tracks/scrum; the companion URLs begin with /tutorials/scrum-day-.

The Agile Manifesto, its principles, and the free Scrum Open assessment provide additional reference points. Use assessment feedback to decide what to revisit; practical understanding also needs experience and reflection.