Workflow: Planning and Running a Delivery Cycle

Overview

This playbook ties every StretchProjects feature together into one repeatable rhythm: set up a board, plan a delivery cycle, run the work through stages, and close out with a review. Follow it once and you'll have a template for every future cycle.

Step 1 — Set up the board

1. Go to Boards and create a board named for the cycle or initiative, e.g. "Sprint 14 – Marketing Site."
2. Confirm it has the standard stages (Backlog → Planned → In Progress → Review → Released).
3. Add a one-line description and set an owner so the board is self-explanatory.

Step 2 — Fill the backlog

1. Create an item for each piece of work, dropping them into Backlog.
2. For each, set at least a Title, Priority, and Item type. Use a template for recurring kinds of work.
3. Record any dependencies between items so sequencing is clear.
4. Set documentation flags (KB / Ops Doc / Changelog) on items whose changes will need docs.

Step 3 — Plan the cycle

1. Review the backlog and drag the items you're committing to into Planned.
2. Assign an owner and assignees to each planned item.
3. Set due dates (and target release dates where relevant) so items appear in the Today and Upcoming queues.
4. Link each item to its customer and related brand/app where applicable.

Step 4 — Run the work

1. As people pick up work, they drag cards from Planned to In Progress.
2. Use the collaboration thread on a card for decisions and questions.
3. When something stalls, note the blocker (on the roadmap, move it to Blocked; on a project board, flag it in the card and keep it visible).
4. Completed work moves to Review for sign-off, then Released.
5. Run daily standups from the Dashboard KPI strip and the Today queue.

Step 5 — Keep documentation honest

Before moving an item to Released, make sure its documentation obligations are met. Check the dashboard's Docs required and Changelog required counts — drive them toward zero for the work you're shipping.

Step 6 — Close out and review

1. Open the Completed queue to confirm what shipped this cycle.
2. Read the Recent activity feed to see how work moved.
3. Look at Items by stage on the dashboard — anything stuck in Review or Blocked is a carry-over and a retro topic.
4. Move genuine carry-overs back to Planned for the next cycle, and Deferred (on the roadmap) for anything postponed.

Example

A five-person team runs two-week cycles. On Monday they create "Sprint 14 – Marketing Site," pull eight backlog items into Planned, assign owners, and set due dates across the two weeks. Each morning they open the dashboard (In progress, Due today, Overdue) and the Today queue. Mid-cycle, one item hits a legal blocker and is flagged; the rest flow to Review then Released, clearing their KB and Changelog flags on the way. On closing Friday they open Completed (six shipped), move the blocked item and one carry-over back to Planned, and note in the retro that Review was a bottleneck.

Tips

• Timebox the cycle and only pull what fits into Planned — a realistic Planned column beats an overstuffed one.
• Keep due dates current so the queues and dashboard stay trustworthy all cycle.
• Make Blocked visible early; a hidden blocker is the most common reason a cycle slips.
• Reuse this board as a template for the next cycle by cloning your setup conventions (naming, stages, standard labels).

Troubleshooting

Work keeps piling up in Review.
That's a capacity or process signal — check Items by stage each cycle and assign explicit reviewers so items don't wait.

Carry-overs are hard to spot.
At close-out, anything not in Released is a carry-over; move it deliberately to Planned or Deferred so the next cycle starts clean.