This manual is for PM-FPX4080 Assessment 2, start to submission. The artifacts in this course are graded on craft rather than on presence, and a paper about agile values earns far less than a paper containing a real backlog. The assessment usually asks you to write items from the position of the person who needs something, attach acceptance criteria specific enough that two readers would agree the work is finished, size the items against a reference, order them with a stated rule, and plan an iteration from measured capacity rather than from ambition. Your scoring guide decides whether that arrives as a backlog, an iteration plan, or both with a definition of done. What follows is our method, then a structure mapped criterion by criterion, then an annotated excerpt. Prefer to hand it off? A premium original sample returns in 24 to 48 hours, revised free until the criteria are met. Your courseroom may print this as PM FPX 4080 Assessment 2 or PM4080 Assessment 2; it is the same deliverable, and PM-FPX4080 Assessment 2 is what this manual walks through.
One honesty note before the manual: Capella revises courses and scoring guides over time, so always write to the exact scoring guide attached to your assessment in the courseroom. The course identity above is verified on capella.edu; the method and structure below are our tutors' approach to it, not Capella's official rubric text.
How PM-FPX4080 Assessment 2 is scored
Every criterion carries its own level, and on a backlog deliverable the four separate on whether two readers would score an item the same way:
| Level | What it means on a backlog and iteration planning deliverable |
|---|---|
| Distinguished | Acceptance criteria two readers would score identically, an ordering rule stated rather than implied, sizing anchored to a named reference item, and a commitment derived from a capacity figure you can see. |
| Proficient | Well-formed items with acceptance criteria and a sensible order. The sizing is consistent, and no reference item is named, so the numbers cannot be checked against anything. |
| Basic | A task list with a user story sentence in front of each line, acceptance left as a description of the feature, and an iteration filled to look busy. |
| Non-performance | A required element is absent, usually the acceptance criteria or the definition of done, and without either the review has nothing to accept. |
A definition of done exists to make the word complete mean the same thing twice. Write it once, apply it to every item, and cover the things people quietly skip: tested, reviewed, documented and deployable. An item that meets its acceptance criteria and fails the definition of done is not finished, and saying so in the paper is worth a criterion.
The PM-FPX4080 Assessment 2 method, step by step
-
Write the item from the position of whoever needs it
Name the person, the thing they need and the reason it matters, then stop. Items written from the system's point of view describe a build instruction, and the criteria are asking for a statement of need that a reader could challenge before any work starts.
-
Attach acceptance criteria that describe an observable outcome
Given a stated starting condition, when a stated action happens, then a stated result follows. Criteria in that shape can be tested, demonstrated at a review, and argued about in advance rather than afterwards, which is the whole point of writing them down.
-
Split by outcome, never by technical layer
Anything too large to finish inside one iteration gets divided, and the division has to leave both halves usable. Half a feature nobody can use is not a delivery, and splitting a booking flow into a database part and a screen part produces two items that cannot be accepted separately.
-
Size against one named reference item
Pick a small, well-understood item, declare it two points, and size everything else against it on a spaced scale. Never convert points to hours in the paper, because the moment you do the estimate stops being relative and becomes a promise. Internal consistency is what a grader can actually check.
-
Order the backlog by a rule you state
Value against effort, risk retired early, dependency order, or a regulatory date. Say which rule you used and why the top three items are on top. A backlog with no stated ordering logic is a wish list, and the criterion is written to notice.
-
Plan from capacity, then submit
Count the hours the team actually has after leave, support duties and ceremonies, and commit only to what fits. Then check that every item in the iteration has acceptance criteria, that the definition of done applies, self-score against the descriptors, and submit with room for a second attempt.
A structure that maps to the criteria
Ranges our tutors use for a backlog with an iteration plan; where the guide asks only for the plan, the capacity work takes the words the backlog would have used.
| Section | What it must do | Guide |
|---|---|---|
| Product and users | What is being built, who benefits, and what each of those people currently does instead. | ~200 words |
| Backlog items | Items written from the user's position, each with testable acceptance criteria. | ~350 words |
| Definition of done | The conditions every item must meet, including the ones teams quietly skip. | ~200 words |
| Sizing | The reference item, the scale used, and the relative sizes with the reasoning for the larger ones. | ~250 words |
| Ordering | The rule applied, why the top items are at the top, and any dependency that forces an order. | ~250 words |
| Iteration plan and references | Capacity after deductions, the commitment, the iteration goal, and current APA both ways. | ~250 words |
Annotated sample excerpt
One item with its acceptance criteria and a capacity calculation, from an original model our team wrote.
Item 12: as a customer whose bike is already in the workshop, I want to add a second job to the same visit so that I collect everything in one trip. Given a bike with an open work order, when a second service is requested inside the same booking, then the job attaches to the existing work order and the collection slot moves to the later of the two estimates.1 Sized at three points against reference item 4, the single-service booking confirmation, which is declared two, and larger only because the collection slot recalculation touches the mechanic day view as well as the customer flow.2 Iteration capacity: five people over two weeks gives a nominal 400 hours, less 24 for one mechanic's leave, 32 for the walk-in support rota and 40 for planning, review and retrospective, which leaves 304 hours and a commitment of 21 points against a five-iteration average of 22.3
- 1The item names the person, the need and the reason, then the acceptance criteria give a starting condition, an action and a result. Two readers would score this the same way.
- 2Sizing anchored to a named reference item, with the reason for the difference stated. Relative estimates are checkable only when the anchor is visible.
- 3Capacity built by deduction rather than assumed, and the commitment set slightly below the observed average rather than at the top of it.
The full premium sample for your exact assessment, written fresh to your scoring guide and issue, is free to request. Study it, revise it into your own voice, and submit work you understand.
The five mistakes that cost Distinguished
- Backlog items with no acceptance criteria. With no testable outcome there is nothing for the review to accept and nothing for the definition of done to be applied to.
- Acceptance written as a feature description. Restating what the item is does not say what would prove it finished, which is the whole function of the criteria.
- Items split by technical layer. A database half and a screen half cannot be accepted separately, so neither is a delivery and neither can be demonstrated.
- Points converted to hours. The conversion turns a relative size into a commitment and destroys the only property that made the estimate useful.
- An iteration filled to look full. Committing to ambition rather than to measured capacity produces carryover, and the planning criterion is written to catch it.
Pre-submission checklist
- Every item written from the position of whoever needs it, with a reason
- Acceptance criteria in a given, when, then shape that two readers would score alike
- Large items split by outcome so both halves remain usable
- One reference item named and declared, with sizing consistent against it
- An ordering rule stated, and the top items justified against it
- Capacity computed by deduction and the commitment set inside it, submitted early in the week
Backlog or iteration plan due?
Send the product, the prompt and the criteria. We write items with testable acceptance criteria, anchor the sizing to one reference item, build capacity by deduction and return a premium original sample inside 24 to 48 hours.