| Course | MT247 Agile and Scrum Methodologies |
|---|---|
| Unit | Unit 2 |
| Paper type | Framework explanation |
| Length | About 900 words, 6 pages double-spaced |
| Format | APA 7 student paper |
| School | Purdue University Global |
| Program | BS in Business Administration |
| Updated | October 2026 |
Free sample paper for MT247 Unit 2
What Each Part Is For: A Unit 2 Framework Explanation of Scrum, Tested Against One Team's Practice
[Student Name]
Purdue University Global
MT247: Agile and Scrum Methodologies
Unit 2 Framework Explanation
[Instructor Name]
[Date]
Larkspur Residential and its app team are composite and illustrative; the descriptions of Scrum follow the 2020 Scrum Guide; the sources cited are real.
The Empirical Basis
Scrum rests on empiricism: decisions are made from what is observed rather than from a detailed plan made in advance. The 2020 Scrum Guide names three pillars for this, transparency, inspection and adaptation (Schwaber & Sutherland, 2020). Work must be visible to the people doing it and to those affected by it; it must be checked often enough to catch problems; and when a check shows something wrong, the plan or the product must change quickly. The Guide adds five values, commitment, focus, openness, respect and courage, which make those pillars possible in a team.
The test for every element below is the same: which inspection or adaptation does it make possible? An element that runs without enabling either is a meeting, not a Scrum event.
The Events
The Sprint is the container for all other events, a fixed period of one month or less in which a usable Increment is produced. It makes inspection regular. Larkspur runs two-week Sprints, but because the vice president adds work mid-Sprint, the container does not hold, and nothing inside it can be inspected against a stable plan.
Sprint Planning sets why the Sprint is valuable, what can be done and how. It inspects the Product Backlog and the team's capacity and adapts both into a Sprint Goal and a Sprint Backlog. For a one-month Sprint it is timeboxed to eight hours. Larkspur's planning lists tickets without a goal, so the team loses a reason to say no to later additions.
The Daily Scrum belongs to the Developers: fifteen minutes in which the people building the Increment look at where the Sprint Goal stands and rearrange the coming day's work around it. Larkspur's forty-minute report to a manager inspects individuals, not progress, and adapts nothing.
The Sprint Review inspects the outcome of the Sprint with stakeholders and adapts the Product Backlog; for a one-month Sprint it is timeboxed to four hours. Larkspur's slide deck inspects a story about the work rather than the work, so the backlog never changes because of it.
The Sprint Retrospective inspects how the last Sprint went, for people, interactions, processes and tools, and adapts the team's way of working; for a one-month Sprint it lasts at most three hours. Larkspur stopped holding it, which means the team has no event in which its process can improve.
The Artifacts and Their Commitments
Each artifact in the 2020 Guide carries a commitment that gives it a target.
Product Backlog, committed to the Product Goal: the single ordered source of work for the product, pointed at one long-term objective
Sprint Backlog, committed to the Sprint Goal: the plan for the Sprint, aimed at one objective that gives the Sprint coherence
Increment, committed to the Definition of Done: a usable step toward the Product Goal that meets the quality standard
Larkspur's backlog has no Product Goal, so ordering by arrival date has nothing to compete with. Its Sprints have no Sprint Goal, so additions cannot be judged against anything. And it has no written Definition of Done, so "finished" varies by developer, which is why the tester finds work called done that has never run on a phone.
Without the commitments, the artifacts are just lists.
The Three Accountabilities
The Product Owner is accountable for maximizing the value of the product and for ordering the Product Backlog. The Scrum Master is accountable for the team's effectiveness and for establishing Scrum as the Guide defines it. The Developers are accountable for creating a usable Increment each Sprint and for their own Sprint Backlog. Rubin (2012) stresses that these are accountabilities, not job titles, and that organizations often fill the titles while leaving the authority where it was. At Larkspur, the titles are filled but the accountabilities sit elsewhere, a problem the next unit takes up.
Why the Pieces Depend on One Another
The parts of Scrum are not a menu. Each one supplies something another needs. Sprint Planning needs an ordered Product Backlog, or the team selects work by guesswork. The Daily Scrum needs a Sprint Goal, or there is nothing to inspect progress toward. The Sprint Review needs a Done Increment, or stakeholders inspect slides. And the Retrospective needs evidence from the other events, or it becomes a complaint session. At Larkspur, dropping the Retrospective and the Sprint Goal did not remove two parts; it weakened every other part, because each relied on them. That is why the team's adoption feels hollow even though every meeting appears on the calendar.
What the Guide Leaves Out
The Guide says nothing about user stories, story points, velocity, burndown charts or planning poker. These are common practices that many teams use with Scrum, but they are not part of it. Cohn (2005) developed much of the story point approach as a separate planning technique. This matters at Larkspur because the development manager treats velocity as a Scrum requirement and a performance measure. Knowing that the Guide does not require it opens the question of whether the team should report it at all, and to whom.
References
Cohn, M. (2005). Agile estimating and planning. Prentice Hall.
Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular agile process. Addison-Wesley.
Schwaber, K., & Sutherland, J. (2020). The Scrum guide. https://scrumguides.org/scrum-guide.html
MT247 Unit 2 instructions, in plain terms
Unit 2 asks students to explain the Scrum framework accurately and show they understand why it is built as it is. The prompt usually expects the empirical basis, the events with their purposes and timeboxes, the artifacts with their commitments and the accountabilities, all drawn from the current Scrum Guide. Explaining purpose earns more than restating definitions, so for each element say what it lets the team inspect or adapt. Applying the explanation to a real or composite team turns a summary into an argument. Many sections also ask what Scrum does not include, such as story points, so readers can tell framework from common practice. About six pages in APA 7, with one or two tables, is a typical length.
How the MT 247 Unit 2 example is put together
The paper opens on the empirical basis and the five values, then sets one test for every element. The events section works through all five, from the container Sprint to the closing Retrospective, each with its purpose, timebox and what Larkspur loses, under a margin note on turning definitions into evidence. The artifacts section pairs each with its commitment and shows the cost of missing ones, and the highlighted line says that without commitments the artifacts are just lists. Rubin's distinction between accountabilities and titles introduces the roles. Another section shows that dropping one part weakens the rest, and a closing section on story points and velocity, citing Cohn, prepares later units under a final note.
Where the points sit in the MT247 Unit 2 rubric
Framework explanations are marked on accuracy against the current Guide, explanation of purpose, application to a case and clear organization. Getting timeboxes, commitments and accountabilities right is the base, and using outdated terms such as Development Team loses points. Instructors reward explanations that say what each element makes possible rather than what it is called. Applying the framework to a team, with specific consequences of misuse, shows understanding. Showing how the parts depend on each other demonstrates the framework is a system, not a list. Separating Scrum from practices commonly added to it, and citing the Guide correctly in APA 7, complete the rubric. Tables that set purpose, inspection and adaptation side by side make the explanation easier to grade.
MT247 Unit 2 help from the desk
Students often copy the Guide's definitions in order, which shows reading but not understanding. Another frequent problem is using terms from older versions of the Guide, such as roles or the three Daily Scrum questions, as if they were still required. Some papers treat story points and velocity as part of Scrum. Others list events without timeboxes or artifacts without commitments. Check every timebox against the length of Sprint you describe. Share the team you want to analyze, and a writer can explain each element through what that team gains or loses by it.
Get an MT247 Unit 2 example written to your instructions
How much application does your section expect beside the explanation itself? Attach the Unit 2 prompt and rubric, plus any team or case to test the framework against. A first explanation costs nothing, arrives in 24-48h and cites the 2020 Scrum Guide directly, each event explained through its purpose. The paper above is an original model document written by our desk, not a submitted student paper and not an official Purdue University Global document.
More MT247 papers and BS in Business Administration samples
- MT247 Unit 1: Discussion Board Post
- MT247 Unit 3: Role Analysis
- MT247 Unit 4: Backlog Ordering Exercise
- MT247 Unit 5: Estimation Exercise
- MT247 Unit 6: Seminar Reflection
- MT247 Unit 7: Sprint Planning Artifact
- MT247 Unit 8: Impediment Analysis
- MT247 Unit 9: Retrospective Design
- MT247 Unit 10: Adoption Assessment
- MT246 Unit 2: Work Breakdown Structure
- MT245 Unit 2: Project Classification Exercise
- MT243 Unit 2: Asset Inventory
- MT242 Unit 2: Program Structure Analysis
MT247 Unit 2 questions, answered
What timeboxes apply to a two-week Sprint?
The Guide sets maximums for a one-month Sprint: eight hours for Sprint Planning, four for the Review and three for the Retrospective, with fifteen minutes for the Daily Scrum whatever the Sprint length. For shorter Sprints it says the events are usually shorter, without fixing numbers. The example quotes the maximums and reports the team's own shorter timeboxes as choices rather than rules.
Is the Sprint Goal allowed to change mid-Sprint?
The Guide says no changes are made that would endanger the Sprint Goal, while the scope of work may be clarified and renegotiated with the Product Owner as more is learned. If the goal becomes obsolete, only the Product Owner may cancel the Sprint. The example uses this to show why mid-Sprint additions from an executive break the arrangement at this team.
Should the paper mention user stories and story points?
Yes, if only to place them correctly. Both are widely used with Scrum and neither appears in the Guide. A paper treating them as required gets a basic fact wrong, while one ignoring them entirely can seem unaware of common practice. The example gives them a short closing section, labeled as complementary practices a team may choose.
Where can I find a free MT247 Unit 2 sample paper?
The complete MT247 Unit 2 framework explanation is printed here. It explains Scrum's events, artifacts and accountabilities by their purposes and tests each against a property company's app team.
Does the MT247 Unit 2 sample treat story points as part of Scrum?
No. It notes that the 2020 Guide says nothing about story points, velocity or burndown charts, which are separate planning practices, and explains why that matters when a manager treats velocity as a requirement.