SAMPLE: a fictional business. Not a client of Adwaizer.

Agile project kickoff pack: Quillmoor Software Inc. (sample)

Prepared by: Adwaizer AI Consulting Inc. · Engagement: Agile project kickoff pack, Starter tier (one product, one team, 7 working days) · Pack version: sample, October 2026

What this page is. This is the pack a client keeps at the end of the Agile project kickoff pack. Quillmoor Software is invented to show the format and depth; the company, its people, its product and its figures do not exist. In a real engagement every goal, story and risk comes from the client's intake, documents and the two working sessions.

How we deliver.

Certified delivery: PMP and PMI-ACP certified; fixed scope and fixed price.
Weekly progress: small deliveries every week, each shown in a live demo.
No surprises: a risk and issue log shared with you, and written acceptance criteria you sign off.

How to read the dates and sizes. Nothing here is a commitment. Every date is marked (estimate) and rests on the team's capacity in section 3. Story sizes are relative story points agreed by the team in the refinement session, not hours. Figures marked (client's figure) are what the fictional founders told us.

Intake questionnaire (as answered)
Discovery session: agenda and notes
Product goal, stakeholders and team
Prioritised backlog (epics, stories, acceptance criteria)
Roadmap (three releases)
Risk register
Definition of ready and definition of done
Ceremonies
Refinement agenda
The board: monday.com columns and set-up
First two sprints: one-page guide
Engagement risk and issue log
Acceptance checklist and sessions held
Milestone submission text

1. Intake questionnaire (as answered)

Filled in by the sponsor on day 1, on a Jotform intake form.

Question	Answer
Company	Quillmoor Software Inc. (invented), Halifax, Nova Scotia; founded 2025
Product	Studiobook: booking, class waitlists and member messages for independent fitness and yoga studios
Where the product is today	A working prototype: studio owners can publish a class schedule and members can book; no waitlist, no payments link, no reminders. 4 studios use it for free (client's figure)
Goal for the next 3 months	Turn the prototype into a product 15 studios use every week, ready to charge for after release 3 (client's figure)
Hard deadline	None; the founders want release 1 before the January sign-up season
Team and roles	6 people: CEO (sponsor), CTO, product designer, 2 full-stack developers, 1 customer success lead who is also the acting product owner
Current tools	GitHub (code and issues), Figma, Slack, Google Workspace; feature ideas in a shared spreadsheet; no board
Ways of working today	Weekly founders' call; developers pick work from the spreadsheet; no sprints
Known features	Waitlist with auto-promotion, class reminders by email and SMS, member check-in, simple reports for studio owners, link to the studio's existing payment provider
Constraints	Two developers only; the CTO also handles infrastructure and support escalations; member data stays in Canada
Known risks	SMS costs unknown; studio owners are slow to give feedback; the CTO is a single point of failure for deployments
Personal or regulated data in scope	Member names, emails and phone numbers in the product; none shared with us. No health or finance data
AI tools for your documents	Yes, for the spreadsheet and the pitch deck; no for any member data
Board tool preference	No preference; open to monday.com or a spreadsheet

2. Discovery session: agenda and notes

Session: 60 minutes, video call, day 2. Attendees: CEO (sponsor), customer success lead (product owner), CTO; Gabriel facilitating.

Agenda (sent the day before)

Time	Item	Output
0-10	Goal for the next 3 months, in one sentence	Draft product goal
10-25	Walk the feature spreadsheet: what studios ask for most	Epic list, first order
25-40	Who decides, who is affected, who must be told	Stakeholder list
40-50	What could stop us	Risks for the register
50-60	Constraints, next steps, the refinement session date	Agreed dates and owners

Notes (summary)

The founders agree the 3-month goal is weekly use by 15 studios, not revenue. Charging starts after release 3.
Waitlists are the most-asked feature: studios fill the 6 a.m. and 6 p.m. classes and turn people away by hand.
Reminders reduce no-shows; studio owners want email first, SMS only if the cost is clear.
Payments stay with each studio's existing provider: Studiobook links to it, it does not take payments.
The product owner speaks to 2 studio owners a week and will bring their feedback to each review.
The CTO is the only person who can deploy; this goes on the risk register (R1).

3. Product goal, stakeholders and team

Product goal. By the end of release 3, 15 independent studios run their weekly class schedule, waitlists and reminders in Studiobook, and at least 10 of them say they would pay for it.

Epics

ID	Epic	Why
E1	Class schedule and booking (harden the prototype)	Today's core, used by 4 studios
E2	Waitlists	The feature studios ask for most
E3	Reminders	Fewer no-shows
E4	Member check-in	Studios still use paper sign-in sheets
E5	Owner reports	Owners want to see which classes fill
E6	Studio onboarding	Reaching 15 studios needs self-serve set-up
E7	Payment provider link	Members pay through the studio's own provider

Stakeholders

Stakeholder	Interest	Influence	How we involve them
CEO (sponsor)	Product goal, fundraising story	High	Attends the review each sprint; owns the go or no-go for each release
Product owner (customer success lead)	Backlog order, studio feedback	High	Orders the backlog; attends every ceremony except the daily stand-up when optional
CTO	Architecture, deployments, cost	High	Refinement and planning; owns technical risks
Developers (2)	Clear, small stories	Medium	All ceremonies
Product designer	Usable flows for owners and members	Medium	Refinement and review
Pilot studio owners (4)	Fewer manual steps	Medium	Invited to every second review; feedback through the product owner
Studio members	Easy booking and reminders	Low	Feedback forms inside the app

Team capacity (basis of every date in this pack)

Two developers at about 7 points each per 2-week sprint, plus the CTO at about 3 points: about 17 points a sprint (estimate, to be replaced by the measured velocity after sprint 2).

4. Prioritised backlog (epics, stories, acceptance criteria)

Ordered by the product owner in the refinement session. Sizes are story points (estimate). R1 = release 1, and so on.

#	ID	Epic	Story	Acceptance criteria	Size	Release
1	S01	E1	As a studio owner, I want to create a recurring class once so that I do not re-enter it every week.	A class can repeat weekly with an end date; editing one occurrence does not change the series unless chosen; the change shows to members within a minute.	5	R1
2	S02	E1	As a member, I want to cancel my booking so that my spot goes to someone else.	Cancel is possible up to the studio's cut-off time; after the cut-off the button explains why it is disabled; the spot is released at once.	3	R1
3	S03	E2	As a member, I want to join the waitlist for a full class so that I can get a spot if one opens.	A full class shows "Join waitlist"; the member sees their position; they can leave the waitlist at any time.	3	R1
4	S04	E2	As a member on the waitlist, I want to be moved into the class automatically when a spot opens so that I do not have to watch for it.	When a booking is cancelled, the first person on the waitlist gets the spot; they receive an email within 5 minutes; nobody is promoted after the cut-off time.	5	R1
5	S05	E2	As a studio owner, I want to set a waitlist limit per class so that the list stays realistic.	Owner can set 0 to 20; 0 turns the waitlist off; members beyond the limit see "Waitlist full".	2	R1
6	S06	E3	As a member, I want an email reminder before my class so that I do not forget it.	Email goes out at the time the studio sets (default 12 hours before); it includes a one-click cancel link; members can turn reminders off.	3	R1
7	S07	E1	As the CTO, I want a second person able to deploy so that a release does not wait on me.	A written deploy checklist exists; one developer has completed a deploy with the CTO watching and one alone.	2	R1
8	S08	E6	As a new studio owner, I want to sign up and publish my first class without help so that I can start the same day.	A new owner can sign up, add the studio's name and timezone, and publish a class in under 15 minutes in a usability test with 3 owners.	5	R2
9	S09	E4	As a front-desk person, I want to check members in from a tablet so that we stop using paper.	Tablet view lists today's classes and booked members; tapping a name marks them present; works on a 10-inch tablet in landscape.	5	R2
10	S10	E4	As a studio owner, I want no-shows recorded automatically so that I can see who books and does not come.	Members not checked in 15 minutes after start are marked "no-show"; the owner can correct a mark.	2	R2
11	S11	E7	As a studio owner, I want to add my existing payment page link to a class so that members pay the way they do today.	Owner can paste a link per class or per studio; the booking confirmation shows it; Studiobook stores no card data.	3	R2
12	S12	E5	As a studio owner, I want to see fill rate per class over the last 4 weeks so that I can change the schedule.	Report shows each class, bookings, capacity and fill rate; can be filtered by week; exports to CSV.	5	R2
13	S13	E3	As a studio owner, I want to choose whether reminders also go by SMS so that I control the cost.	SMS is off by default; owner turns it on per studio; the settings page shows the monthly SMS count.	5	R2
14	S14	E6	As a new studio owner, I want to import my members from a spreadsheet so that I do not type them in.	Accepts a CSV with name, email, phone; shows rows it cannot read and why; imports nothing until the owner confirms.	5	R2
15	S15	E1	As a member, I want to see my upcoming bookings in one list so that I know my week.	List shows upcoming bookings and waitlist positions in date order; each has cancel or leave.	2	R2
16	S16	E5	As a studio owner, I want a weekly summary email so that I see the week without logging in.	Sent Monday morning in the studio's timezone; shows bookings, no-shows and the fullest and emptiest classes; owner can turn it off.	3	R3
17	S17	E2	As a studio owner, I want to see the waitlist for each class so that I can decide to add a class.	Class page lists waitlisted members in order; the owner can remove one with a reason.	2	R3
18	S18	E4	As a member, I want to check myself in with a code at the door so that the front desk is not a queue.	A 4-digit code per class shown on the tablet; members enter it in the app within 15 minutes of start; wrong codes are refused.	5	R3
19	S19	E6	As a studio owner, I want to invite instructors with their own login so that they can see their classes.	Owner invites by email; instructors see only their classes and check-in; they cannot change settings.	5	R3
20	S20	E3	As a member, I want to add a class to my calendar so that it sits with my other plans.	Booking confirmation includes an "Add to calendar" file; cancelling sends an update.	2	R3
21	S21	E1	As a studio owner, I want to cancel a class and tell everyone booked so that nobody shows up for nothing.	Owner cancels with an optional message; all booked and waitlisted members get an email within 5 minutes.	3	R3
22	S22	E5	As the CEO, I want a simple usage dashboard across studios so that I can track the product goal.	Shows active studios per week (at least one class with bookings) and bookings per week; visible only to Quillmoor staff.	3	R3

Below the line (not ordered yet): member accounts across several studios; class packs and memberships; a mobile app; instructor substitutions. The product owner revisits these at the release 2 review.

Totals (estimate): R1 23 points, R2 32 points, R3 23 points.

5. Roadmap (three releases)

Two-week sprints starting Monday 2 November 2026 (estimate), at about 17 points a sprint (estimate). The roadmap is reviewed at the end of every sprint and dates move with the measured velocity.

Release	Goal	Stories	Sprints	Target date	Measure of success
R1: Full classes stop losing members	Waitlists and reminders work for the 4 pilot studios	S01-S07	Sprints 1-2	27 November 2026 (estimate)	Pilot studios use the waitlist on at least half of their full classes
R2: A studio can start alone	Self-serve onboarding, check-in, payment link, first report	S08-S15	Sprints 3-5	29 January 2027 (estimate); sprint 3 runs 30 November to 11 December, then a holiday break, sprint 4 starts 4 January	10 studios active in a week
R3: Owners see the value	Reports, instructor logins, self check-in, cancellations	S16-S22	Sprints 6-7	26 February 2027 (estimate)	15 studios active in a week; 10 say they would pay (product goal)

Dependencies. S04 needs S03. S08 and S14 are needed before inviting studios beyond the pilot. S13 waits on the SMS cost decision (R2 in the risk register). S22 needs S09 for activity data.

6. Risk register

Likelihood and impact: 1 low to 5 high, scored by the owners in the refinement session. Score = likelihood × impact. Reviewed at each sprint review.

ID	Risk	Likelihood	Impact	Score	Owner	Response	Trigger
R1	Only the CTO can deploy, so releases wait on one person	4	4	16	CTO	Reduce: story S07 in sprint 1; a written deploy checklist	Any release delayed more than 1 day by deploy availability
R2	SMS reminders cost more than studios will pay for	3	3	9	CEO	Avoid for now: email first; SMS off by default (S13); decide after a 2-week pilot count	Pilot SMS count projects above the cost line the CEO set
R3	Studio owners give little feedback, so we build the wrong thing	4	3	12	Product owner	Reduce: 2 owner calls a week; pilot owners invited to every second review	Fewer than 2 owner conversations in a sprint
R4	Velocity is lower than 17 points, so R1 misses the January sign-up season	3	4	12	Product owner	Accept and watch: S01-S06 are first; S07 can slip to sprint 3 if needed	Sprint 1 completes fewer than 12 points
R5	Holiday absences in late December reduce capacity	4	2	8	CTO	Reduce: no sprint between 14 December and 1 January (estimate)	Leave calendar shows both developers away in the same week
R6	Member data stored outside Canada by a new service (email or SMS sender)	2	4	8	CTO	Avoid: choose senders with Canadian data storage or no stored member data; check before adding any service	A new service is proposed for member data
R7	Waitlist auto-promotion books a member who no longer wants the class	3	2	6	Product owner	Reduce: email with one-click release; no promotion after cut-off (S04)	More than 3 complaints a month about unwanted promotion
R8	The CTO's support load crowds out sprint work	3	3	9	CEO	Reduce: customer success lead takes first-line support; CTO capacity planned at 3 points	CTO spends more than a day a week on support for 2 weeks

7. Definition of ready and definition of done

Definition of ready (a story may enter a sprint when)

It is written as "As a ..., I want ..., so that ..." and the product owner agrees with it.
It has acceptance criteria the team can test.
It is sized by the team and is 5 points or smaller; anything larger is split.
Designs are attached in Figma when it changes a screen.
Dependencies are done or planned in the same sprint.
Any question about member data is answered (where it is stored, who sees it).

Definition of done (a story is done when)

All acceptance criteria pass, checked by someone other than the developer.
Code is reviewed and merged on GitHub; automated tests pass.
It is deployed to the staging site and shown at the sprint review.
Help text or release notes are updated where members or owners see a change.
No new open bug of high severity.
The product owner accepts it at the review.

8. Ceremonies

Sprint length: 2 weeks, Monday to the second Friday. All times Atlantic time.

Ceremony	Purpose	Attendees	Timebox	When
Sprint planning	Agree the sprint goal and pull ready stories up to capacity	Product owner, developers, CTO, designer	90 min	Sprint day 1, 10:00
Daily stand-up	Share progress toward the sprint goal and raise blockers	Developers, CTO, designer; product owner optional	15 min	Every day, 9:30
Backlog refinement	Split, clarify and size the next stories so they meet the definition of ready	Product owner, developers, CTO, designer	60 min	Sprint day 6 (Monday of week 2)
Sprint review (demo)	Show done stories, get feedback, update the roadmap	Whole team, CEO; pilot studio owners every second review	45 min	Last Friday, 14:00
Retrospective	Choose one or two improvements for the next sprint	Whole team	45 min	Last Friday, 15:00

Agenda templates

Sprint planning. (1) Product owner proposes the sprint goal, 10 min. (2) Review capacity: leave, support load, last velocity, 10 min. (3) Pull stories from the top of the backlog, confirm each meets the definition of ready, 50 min. (4) Confirm the goal and the plan, note risks, 20 min.

Daily stand-up. Each person: what moved toward the sprint goal, what is next, anything blocking. Blockers are solved after the stand-up by the people needed.

Sprint review. (1) Sprint goal and what was done, 5 min. (2) Demo of each done story on staging, 25 min. (3) Feedback and new ideas into the backlog, 10 min. (4) Roadmap and risk register check, 5 min.

Retrospective. (1) Check-in, 5 min. (2) What helped, what got in the way, 20 min. (3) Pick at most two actions with an owner, 15 min. (4) Check last sprint's actions, 5 min.

9. Refinement agenda

Used in the 90-minute refinement and planning session on day 5, and as the template for every later refinement.

Time	Item
0-10	Product goal and roadmap walk-through
10-45	Top of the backlog, story by story: read the story, check acceptance criteria, split anything over 5 points, size
45-60	Risk register with the owners: confirm likelihood, impact, response and trigger
60-80	First sprint goal and sprint 1 plan
80-90	Open questions, owners and dates

Outcome of the sample session: S01-S22 sized; two stories split (the original "waitlist" became S03 and S04; "onboarding" became S08 and S14); sprint 1 goal agreed (section 11); R1 and R4 owners confirmed.

10. The board: monday.com columns and set-up

Quillmoor had no board, only a spreadsheet. We offered to keep the spreadsheet or move to monday.com; they chose monday.com. We're a monday.com partner, so we may earn a referral fee; the recommendation stands on fit. The same columns work in Jira, Linear or Trello.

Board: "Studiobook product backlog". Groups: Sprint 1, Sprint 2, Next (ready), Backlog (not ready), Done.

Column	Type	Values or use
Story	Item name	"S04 Auto-promote from waitlist"
Epic	Dropdown	E1-E7
Release	Dropdown	R1, R2, R3, Later
Status	Status	Not ready, Ready, In progress, In review, Done
Story points	Numbers	1, 2, 3, 5 (sum shown per group)
Owner	People	Developer working on it
Acceptance criteria	Long text	From section 4
Priority order	Numbers	Backlog position set by the product owner
Depends on	Connect boards / text	Story IDs
Sprint	Dropdown	Sprint 1-7
GitHub link	Link	Pull request

Second board: "Studiobook risk register" with the columns of section 6 (ID, risk, likelihood, impact, score as a formula, owner, response, trigger, status).

Set-up done in the engagement: both boards created from the export of sections 4 and 6; the team invited by their own admin; one automation ("when Status changes to Done, move item to group Done"). We used a guest account limited to these two boards and removed it at handover.

11. First two sprints: one-page guide

	Sprint 1	Sprint 2
Dates	2-13 November 2026 (estimate)	16-27 November 2026 (estimate)
Sprint goal	A member can join a waitlist and is told when they get a spot	Members get reminders, and the CTO is no longer the only deployer
Stories	S01, S02, S03, S04 (16 points)	S05, S06, S07 (7 points) plus the top of release 2 if capacity allows: S15 (2 points)
Demo at the review	Book a full class, join the waitlist, cancel from another account, show the promotion email	A reminder email arriving with a cancel link; a developer deploying alone
Risks to watch	R4 (velocity), R7 (unwanted promotion)	R1 (deploys), R5 (holiday absences ahead)
After the sprint	Measure velocity; product owner updates the roadmap dates	Second measured velocity replaces the 17-point estimate; release 1 goes live 27 November (estimate) if the review accepts it

The first week, day by day. Day 1: sprint planning. Days 2-5: stand-ups, building S01-S02. Day 6: refinement of S08-S10 for later sprints. Days 7-9: S03-S04. Day 10: review, retrospective.

When something goes wrong. A story is bigger than thought: split it and move the rest back to the backlog, do not extend the sprint. A blocker lasts more than a day: the product owner decides whether to swap the story out.

12. Engagement risk and issue log

Kept by Adwaizer during the 7 working days and handed over with the pack.

ID	Type	Description	Owner	Status
L1	Risk	The sponsor may miss the refinement session (travel)	Gabriel	Closed: session moved to day 5 morning, sponsor attended
L2	Issue	Feature spreadsheet had duplicate rows for reminders	Product owner	Closed: merged into S06 and S13
L3	Risk	Member data could reach our drafts through the spreadsheet	Gabriel	Closed: client removed the member tab before sharing; AI tools used on documents only, as the intake allowed
L4	Issue	SMS cost line not known, so S13 cannot be ready	CEO	Open, moved to the client's risk register as R2

13. Acceptance checklist and sessions held

#	Item (from the kit's acceptance list)	Where in this pack	Received
1	A prioritised backlog with user stories and acceptance criteria for the first release	Section 4 (S01-S07 for release 1; S08-S22 beyond)	☐
2	A roadmap with goals per release and dates labelled as estimates	Section 5	☐
3	A risk register with owner, response and trigger per risk	Section 6	☐
4	The ceremonies page and the definition of ready and done	Sections 7 and 8	☐
5	The sessions held: discovery, refinement and planning, handover	Below	☐

Session	Length	When	Attendees
Discovery	60 min	Day 2	CEO, product owner, CTO, Gabriel
Refinement and planning	90 min	Day 5	Whole team, Gabriel
Handover	30 min	Day 7	CEO, product owner, Gabriel

A missing or wrong item is fixed within 5 working days at no charge. Quillmoor owns this pack; Adwaizer keeps its templates.

14. Milestone submission text

Hi, the Agile kickoff pack for Studiobook is ready. It includes the prioritised backlog (22 stories with acceptance criteria, release 1 ready for sprint 1), a three-release roadmap with dates marked as estimates, the risk register with owners, responses and triggers, the definition of ready and done, the ceremonies page with agenda templates, a first-two-sprints guide, and your two monday.com boards. We held the discovery, refinement and planning, and handover sessions. The checklist at section 13 lists each item; if anything is missing or wrong, tell me and I'll fix it within 5 working days. Thank you, and good luck with sprint 1.