Plain-language Scrum guides, and what the simulator does and how to use it.
The Sprint Goal is the single objective for a Sprint. It answers why the Sprint is worth doing, gives the team a reason to work together instead of on separate items, and lets the scope bend while the purpose stays fixed. A good goal says what will be true at the end, can be checked at the Sprint Review, and is smaller than the Product Goal it serves.
Legacy Migration is the hardest scenario in Scrumagic. A water company's billing system runs on servers whose lease ends in eighteen weeks, and the job is to move it without changing a single invoice. The work is invisible, the stakes are exact to the cent, and the sponsor cannot see progress. This walkthrough covers the project, the people and the decisions, with no spoilers.
The Sprint Backlog is the plan for one Sprint: the Sprint Goal (why), the Product Backlog items chosen (what) and an actionable plan to deliver them (how). It belongs to the Developers, and they update it all through the Sprint as they learn. A good one has enough detail that the team can inspect its progress at the Daily Scrum, and not so much that updating it becomes the work.
Hospital Data Platform is an expert scenario in Scrumagic. A hospital needs bed-occupancy and wait-time dashboards before winter pressure begins. The code works on clean samples and the real data does not. This walkthrough covers the project, the people and the decisions, with no spoilers.
A Sprint is a fixed-length event of one month or less, and every other Scrum event happens inside it. It gives a team a regular rhythm of planning, building, inspecting and adapting. Its length is the team's first big planning decision, and the main rule is that the Sprint Goal is not endangered once it starts.
Logistics API is an advanced scenario in Scrumagic. A freight company has a fixed budget and twelve weeks to launch a tracking and rate-quote API before its biggest partner goes live. The users are developers, and once they build on it, changing course gets expensive. This walkthrough covers the project, the people and the decisions, with no spoilers.
In Scrum, "Developers" means everyone on the team who creates any part of the Increment, not only programmers. They own four things: the plan for the Sprint, the quality bar set by the Definition of Done, the daily adjustment toward the Sprint Goal, and holding each other accountable. Nobody outside the Developers tells them how to turn backlog items into working product.
The Scrum Master is accountable for establishing Scrum and for the team's effectiveness. In practice that means teaching, coaching, removing obstacles and protecting the events, for the team, the Product Owner and the wider organisation. The Scrum Master has no authority over the work itself, which is why the role depends on influence, not instruction.
Donation Portal is an intermediate scenario in Scrumagic. A food bank has a fixed budget, a grant that expires with the giving season, and a board, a major donor and a volunteer coordinator who all want something in the first release. This walkthrough covers the project, the people and the decisions, with no spoilers.
A Scrum Team is one small group that holds every skill needed to deliver a working Increment each Sprint. It has one Scrum Master, one Product Owner and the Developers, and no sub-teams or hierarchy inside it. The Scrum Guide gives it a typical size of ten or fewer. The SBOK uses the words "Scrum Team" for a narrower group, which is the most common source of confusion.
The Scrum Guide names five values: commitment, focus, openness, respect and courage. They are not posters. The Guide says that when the team embodies them, transparency, inspection and adaptation come to life and build trust, and that every decision and step should reinforce them. Each value shows up as specific behaviour in the events, and each can be tested against what a team actually does.
Empirical process control means deciding from what has actually been observed instead of from a detailed plan made up front. Scrum rests on three ideas: transparency, so that the work can be seen; inspection, so that it is looked at often enough to notice problems; and adaptation, so that something changes when a problem shows. Remove any one and the other two stop working.
We use analytics cookies to see which pages help and which don't. Scrumagic works the same whichever you choose, and you can change your mind any time from "Cookie settings" in the footer. Privacy Policy.
