Backlogs and iteration planning

A backlog is a regularly reviewed list of possible future work. An iteration plan is the work selected for a particular period, with a clear goal. Adding something to the backlog is not a promise to finish it this week.

What belongs in a backlog

Keep user needs, fixes, experiments and improvements whose value you can explain. Give an idea enough context: who needs it, what would change and what remains unknown. A passing thought can stay in your notes until you decide whether it deserves the team's attention.

Do not describe the entire list in equal detail. Near-term candidates need clarity; distant possibilities need enough context to pick them up without detective work.

Prepare tasks for selection

Clarify the outcome. Replace “work on bookings” with “the customer sees a confirmation after submitting the form”.
Split oversized work. Find a piece you can check separately. See breaking down big initiatives.
Record dependencies. If email access is required, note who can provide it and when. Investigate an unknown with a small experiment instead of hiding it inside an estimate.
Order the discussion. Consider value, essential dependencies and significant risks first. This is planning advice, not an automatic Plynno ranking feature.
Count available time. Subtract recurring responsibilities, account for different skills and leave room for uncertainty. Two hours of design time cannot replace two hours of email configuration.

Example: backlog → goal → plan → review

A repair shop wants to simplify bookings. Its small backlog contains:

A request form with three required fields: about 4 hours.
A confirmation message: 3 hours, dependent on email access.
An end-to-end booking check: 2 hours, after the first two tasks.
Updated photographs: 4 hours.
Discount codes: scope still unknown.

The weekly goal: a trial customer can book and receive a response. With 12 hours available, the team selects the first three tasks, totalling 9 hours, and leaves 3 for clarification and fixes. These are illustrative estimates, not a universal buffer rule. Email access is checked before choosing the plan. Photographs and discount codes remain future candidates.

The review: the customer submits a request, but the message goes to spam. Instead of automatically carrying everything forward, the team clarifies the remaining delivery work and compares it with other needs. The next goal may be reliable confirmation rather than more features.

Do this in Plynno

Create tasks in the relevant Space. In “Sprints”, select that Space and create or open a draft. “Space backlog” shows unfinished, unarchived tasks without a current sprint membership. It is the available set of cards, not every idea from every Space.
Clarify each card's title and description and add subtasks if useful. Record the expected outcome, rough effort and dependencies in the description; this example does not require a dedicated estimate field.
Enter the draft's goal and dates. Use “To sprint” on the three selected cards and “To backlog” to undo an inclusion. On desktop you can also drag cards between panels; on a phone use the transfer buttons.
If a card is missing, check the Space, search, calendar filter and “Mine”, and whether it already belongs to another sprint. Do not create a duplicate straight away.
Start the sprint using the sprint guide. In an active sprint, open “Backlog” to inspect available work.
In the summary, choose “Backlog” or “Next sprint” for unfinished cards. The latter requires a selected next draft. Unfinished work defaults to the backlog. The summary covers the entire sprint, regardless of search and filters.

Handle unfinished work deliberately

Name the reason first: oversized work, an external dependency, a changed need or insufficient time. Record what is ready and what remains. Make the next action smaller or clearer before deciding when to take it on. Spending the estimated hours does not make the whole task complete.

Keep the backlog useful

Review near-term candidates weekly or before each iteration. Remove duplicates, clarify vague entries, drop obsolete work and check dependencies. Every few cycles, review the distant possibilities too. “We will not do this” is a useful planning decision when an idea has no clear value.

Common mistakes include selecting easy cards without a shared goal, hiding dependencies, filling every available hour and reusing the old plan without reconsidering it. A short regular task review helps.