| Course | BU 433 Agile Project Management |
|---|---|
| Unit | Unit 2 |
| Paper type | User stories with acceptance criteria |
| Length | About 1,250 words, 7 pages |
| Format | APA 7 student paper |
| School | Herzing University |
| Program | BS in Project Management |
| Updated | September 2026 |
Free sample paper for BU 433 Unit 2
One Story Too Big to Build, Split Into Four: User Stories With Acceptance Criteria for a Composite Self-Storage Chain's Online Move-In
Student Name
Business, Herzing University
BU 433: Agile Project Management
Instructor Name
January 28, 2026
One Story Too Big to Build, Split Into Four: User Stories With Acceptance Criteria for a Composite Self-Storage Chain's Online Move-In
What These Stories Cover
Prairie Vault Storage, the composite Kansas and Missouri self-storage chain used in this course, is building online move-in, letting a renter go from picking a unit to holding a working gate code with no stop at the office counter. The fit analysis recommended building the renter-facing experience iteratively while the lease text and the gate integration follow fixed milestones. This document writes the first stories for that experience. Each story takes the form "As a [person], I want [something], so that [reason]," and each carries acceptance criteria written as conditions a tester who has never met the team could check.
Cohn (2004) describes a user story as a placeholder for a conversation rather than a full specification, with the acceptance criteria recording what the conversation settled. The stories below were drafted with the product owner, the director of operations, and reviewed with a facility manager, since two of the stories affect staff rather than renters. Lucassen et al. (2016) found that stories written by practitioners often fail simple quality checks, such as describing a solution instead of a need or bundling several needs into one, and each story here was checked against those faults before criteria were added.
Story 1: Seeing What Is Available
As a renter comparing facilities on my phone, I want to see which unit sizes are available at a facility and what each costs per month, so that I can choose without calling the office.
Acceptance criteria. Given a facility with at least one available unit of a size, when I open that facility's page, then I see the size, its monthly rate and any online discount, and the rate shown equals the rate that will appear on my lease. Given a size with fewer than five units available, then the page shows how many remain. Given a size with none available, then the page shows "Join the waitlist" and no price. Given a unit rented at the counter, then it disappears from the website within 15 minutes.
Story 2 and Why It Was Split
The first draft of the central story read: "As a renter, I want to complete my whole move-in online, so that I never have to visit the office." It fails as a story for three reasons. It could not be finished in a two-week sprint, since it includes identity checking, lease signing, payment and gate access. It cannot be estimated as one item, because the lease depends on counsel's approval and the gate code on the vendor's interface, neither of which the team controls. And it cannot be tested as one piece; a tester would not know which failure to report. The story was split along the steps a renter actually takes, so that each piece delivers something a renter can use and can be released separately. The Scrum Guide describes backlog items as being refined until they are small and clear enough to be finished within one sprint (Schwaber & Sutherland, 2020), and the four pieces below meet that test where the original did not.
Story 2a: Confirming Who Is Renting
As a renter who has chosen a unit, I want to confirm my identity by photographing my driver's license, so that the facility knows who is renting without seeing me in person.
Acceptance criteria. Given I have selected a unit, when I upload a clear photo of a valid license, then my name and address fill the rental form and I can edit only my phone number and email. Given the photo is unreadable, then I am asked to retake it and told what went wrong. Given the name on the license does not match the name on my payment card, then the rental continues but is flagged for the manager to review before a gate code is issued.
Story 2b: Signing the Lease
As a renter, I want to read and sign the lease on my phone, so that I do not have to print anything or come to the office.
Acceptance criteria. Given the lease version approved by counsel is loaded, when I reach the signing step, then the sign button stays disabled until I have opened each required notice section. When I sign, then a copy of the signed lease is emailed to me within five minutes. Then the stored record includes the lease version number, the time and the device used. Given no approved lease version exists for the facility's state, then online signing is unavailable and I am offered an office appointment instead.
Story 2c: Paying
As a renter, I want to pay the first month's rent and the administration fee by card, so that the unit is held for me.
Acceptance criteria. Given a signed lease, when I pay successfully, then the unit is marked rented in the management system and a receipt is emailed. Given the card is declined, then the unit stays held for 30 minutes and I can try another card. Given I do not complete payment within 30 minutes, then the hold is released and the unit reappears online.
Story 2d: Getting In the Gate
As a renter who has paid, I want to receive my gate code by text message, so that I can move my belongings in the same day.
Acceptance criteria. Given payment has succeeded and no review flag is set, when the gate system confirms the new code, then I receive a text with the code, the facility address and the access hours within two minutes. Given the gate system does not confirm within ten minutes, then the facility manager is alerted to issue the code by hand, and I receive a message saying the code is on its way.
Story 3: Saving Progress
As a renter interrupted partway through, I want my progress saved, so that I can finish later without starting over.
Acceptance criteria. Given I leave after choosing a unit, when I return on the same device within 24 hours, then I resume at the step I left. Given I return after 24 hours, then I start again and the unit is no longer held.
Story 4: The Manager's Morning View
As a facility manager, I want to see every online move-in for my facility when I open the office, so that I can check each unit is clean and unlocked before the renter arrives.
Acceptance criteria. Given at least one online move-in since closing, when I log in, then the dashboard lists each one with unit number, renter name, move-in time and any review flag, sorted by move-in time.
What the Criteria Leave Open
Some things are deliberately not specified. The visual layout of each screen is left to the designer and developers, since fixing it in criteria would turn a story into a specification. The identity check does not name a vendor or technology; only the outcome is required. The wording of the gate code text is left open, apart from the three facts it must contain. A Spanish-language version is not mentioned, because the product owner wants to see who completes move-ins before deciding. Leaving these open keeps the stories negotiable, which Cohn (2004) treats as a defining quality of a good story, while the criteria fix only what a renter or manager must be able to rely on. The company, its staff and these stories are composites written for this course.
References
Cohn, M. (2004). User stories applied: For agile software development. Addison-Wesley.
Lucassen, G., Dalpiaz, F., van der Werf, J. M. E. M., & Brinkkemper, S. (2016). Improving agile requirements: The Quality User Story framework and tool. Requirements Engineering, 21(3), 383-403. https://doi.org/10.1007/s00766-016-0250-x
Schwaber, K., & Sutherland, J. (2020). The Scrum guide: The definitive guide to Scrum: The rules of the game. https://scrumguides.org/scrum-guide.html
Reading the BU 433 Unit 2 instructions
For Unit 2, BU 433 asks students to write user stories for a product and attach acceptance criteria. Most prompts want five to ten stories in the standard form naming a user, a need and a benefit, criteria that are specific and testable, and evidence that the stories meet quality guidelines such as INVEST. Many instructors ask students to show one story being split and to explain why it was too large. Given-when-then format is common but not always required. Stories should come from one product rather than scattered examples. The deliverable is usually three to five pages in APA 7, with each story set out clearly. A short note on what the criteria intentionally leave to the team is often rewarded.
How the BU 433 Unit 2 example is put together
The sample opens by placing the stories in the online move-in project and describing who helped write them. Story 1 covers seeing availability and price, with criteria for few units, no units and counter rentals disappearing online. The next section shows the original central story, explains three reasons it fails and cites the Scrum Guide on sizing. Four split stories follow for identity, lease signing, payment and gate code, each with its own criteria, including a fallback when the gate vendor does not respond. Two further stories cover saved progress and the manager's morning view. The closing section lists what is deliberately unspecified, such as screen layout and the identity vendor, and explains why leaving these open keeps the stories negotiable.
Where the points sit in the BU 433 Unit 2 rubric
Herzing's grading for this unit usually covers the format and quality of the stories, the quality of the acceptance criteria, story splitting, relevance to the product and presentation. Story quality earns points when each describes a user's need rather than a technical solution and could be delivered on its own. Criteria are judged on whether a tester could check them without asking the author, which means measurable conditions and edge cases. The splitting criterion rewards a clear explanation of why the original story was too large and a split that keeps value in each piece. Relevance scores highest when stories form a coherent slice of one product. Instructors also look for awareness of dependencies, such as legal approvals, reflected in the criteria.
BU 433 Unit 2 help: mistakes that cost points
Many story sets are marked down for describing solutions, for example as a user I want a dropdown menu, instead of needs. Another common mistake is criteria that cannot be tested, such as the page should load quickly or the process should be easy. Students frequently write only happy-path criteria and skip failures like declined payments or missing data. Some stories bundle several needs, and the paper never splits any, even when asked. Others are written from the developer's point of view rather than the user's. Stories copied from real apps without adaptation read as generic. Finally, specifying every visual detail in the criteria turns a story into a specification and removes the conversation stories are meant to prompt.
Get a BU 433 Unit 2 example written to your instructions
Forward the Unit 2 instructions with your BU 433 rubric and the product or scenario the assignment fixes. We write a custom example with the reason clause doing real work, criteria written as conditions anybody could check, one oversized story split by outcome and a note on what stays open. First custom sample free, returned in 24 to 48 hours.
More BU 433 papers and project management samples
- BU 433 Unit 1: Agile principles and fit analysis
- BU 433 Unit 3: Backlog with prioritization basis
- BU 433 Unit 4: Estimation exercise
- BU 433 Unit 5: Sprint plan
- BU 433 Unit 6: Ceremony analysis
- BU 433 Unit 7: Retrospective with a committed change
- BU 433 Unit 8: Hybrid or scaling analysis
- BU 345 Unit 2: Charter and stakeholder register
- BU 396 Unit 2: Risk identification workshop output
- BU 442 Unit 2: Cost estimate with basis
- BU 434 Unit 2: Elicitation plan
BU 433 Unit 2 questions, answered
How many stories does the assignment want?
Whatever the instructions set, and where nothing is fixed a small set treated properly beats a long list. Six stories with real criteria show more than twenty written to a template, because the criteria are where the credit sits and they are what most drafts skimp on. Put the effort you save into the one you split.
Do the criteria have to use the given, when, then form?
Only if the instructions ask for it. The form is popular because it forces a starting state, an action and an observable result, and criteria written as a list of features usually skip the first of those. If you use plain sentences instead, keep the same three elements present so every condition still has an answer somebody could give.
Can stories come from a real product I use?
Yes, and working from something you actually use produces better criteria than inventing a product does, since you know how it behaves. Keep to what any customer can see. A product you build at work is different: its backlog, its roadmap and the reasons behind its ordering are the employer's, and those are the parts that would make the stories interesting.
Where can I find a free BU 433 Unit 2 sample paper?
This page carries the full BU 433 Unit 2 user stories with acceptance criteria for free, including the split story and margin notes. For stories about your own product, forward the assignment and a no-cost custom set is written, generally within 48 hours.
How do I split a story for BU 433 Unit 2?
Split along the steps a user actually takes, so each piece still gives them something usable. The sample breaks complete my move-in online into identity, lease, payment and gate code, each small enough for one sprint and testable alone.