Small-Team Agile Collaboration in Practice with Leantime

This post is an AI translation of the Chinese original. If there are any discrepancies, the Chinese version takes precedence.

Lately, I’ve been reviewing project management methodologies across a large program I run as a Technical Project Manager.

No matter whether a large program uses SAFe or another scaling framework, once the work breaks down into engineering sub-projects, individual teams usually operate in an Agile mode. That means any real retrospective on program management has to start with how small teams collaborate day to day.

Most engineering teams already know the Agile Manifesto and core Agile theory inside out. In practice, though, almost every team customizes how they work and pairs their process with different tools.

Across the program I manage, quite a few sub-projects have slipped into a “fake Agile, real Waterfall” pattern—more like iterative spiral management that simply chops one giant waterfall into a series of smaller waterfalls.

Because of that, I wanted to step back and look at collaboration from a tool-design perspective using an open-source, self-hosted tool like Leantime, and ask a practical question: how can a tool help a small team run genuine Agile collaboration?

To explore this, I worked through a thought experiment with Gemini 4 Argon around an 8-person engineering team (1 PO, 1 Tech Lead doubling as SM, 5 developers, and 1 QA/DevOps engineer) running two-week sprints on Leantime v3.9.8.

While discussing the workflow, I also test-drove these practices on my own self-hosted Leantime instance. Overall, the setup felt practical and grounded enough for real-world use, so I compiled our discussion and hands-on walkthrough into the guide below. If you’re also figuring out how to make Agile work for a small team, I hope these notes give you a useful reference.

Figure Out What Problem the Tool Should Solve First

When picking a collaboration tool for a small team, I don’t care much about how long the feature list is. What I care about is whether it forces everyone to maintain a second layer of records disconnected from the real work. If people only update cards for status reports, switching tools won’t fix anything.

I decided to try Leantime because it keeps the backlog, milestones, sprints, retrospective boards, and wiki inside a single project space, which cuts down on copying context across different platforms. Still, having those modules in one place doesn’t automatically create an Agile workflow. Before tweaking fields and columns, a team needs to agree on three basics: what information is worth writing down, what “Done” actually means, and who makes the call together when plans change.

Three Things That Matter More Than a “Complete” Process

On a two-week sprint cadence (starting Monday of Week 1 and ending Friday of Week 2), it helps to start with three working principles and adjust them in retrospectives based on how they hold up:

Records Should Help the Work Move

• Skip fields that only exist for reporting: Cards are there to help the team collaborate, so don’t make every custom field mandatory. Time tracking works best when used selectively—for instance, to see how much capacity goes into shared operational support—rather than forcing everyone to account for every hour of their day.
• Keep card fields minimal: A good card only needs five clear pieces of information: what it is (Title & Description), who owns it (Assignee), where it belongs (Milestone & Sprint), how big it is (Effort), and how urgent it is (Priority).
• Keep everyday updates lightweight: Moving a card’s status or dropping a one-line progress note should take seconds. Refining requirements deserves real thought; updating the board shouldn’t. If maintaining cards keeps interrupting engineering flow, you probably have too many fields or too many rules.

Finishing Beats Starting More Work

• Run meetings around blockers, not status recitals: Daily standups shouldn’t be a round-robin report to management. It’s much more useful to look at the board together and ask: “Which card is stuck, and what will it take to move it right today?” Timeboxing keeps the conversation focused; deeper technical debates can happen right after with only the people involved.
• Measure completion by end-to-end Done: Finishing subtasks or writing code doesn’t mean a story is done. A parent card only moves to Done when it meets the team’s shared Definition of Done (DoD). Whether it actually delivers business value still depends on post-release usage and feedback. Being “demoable” is not a substitute for quality gates.
• Surface blockers as soon as they happen: When a technical snag or ambiguous requirement comes up, prefix the Leantime card title with [🔴Blocked] right away and @mention the relevant person in the comments. Solve problems during daily flow instead of waiting until Friday to announce a delay.

Discussions Can Happen Anywhere, Decisions Need a Home

• Make work traceable: Product features, tech debt, and bug fixes should all map to a card or a shared support bucket card. During a production incident, restore service first and log the card afterward. Small support tasks under two hours can be batched into a shared card after you handle them—never delay an urgent response just to fill out a form.
• Bring conclusions back to the card: Chat apps are great for quick back-and-forth, but updated Acceptance Criteria (AC), API contracts, and edge cases need to make their way back into the card description, comments, or project wiki. Whoever picks up the work later shouldn’t have to piece requirements together from chat history.
• Keep records connected: Milestones, the backlog, sprints, retrospective canvases, and the wiki can live in the same Leantime project and link to one another. Putting them in one system doesn’t make them complete on its own—the team still has to keep those links and notes current.

Map Collaboration Concepts into the Tool Instead of Forcing a 1:1 Fit

Before jumping into a tool, agreeing on what your terms mean matters more than configuring fields. Below is the mapping I use to turn abstract Scrum concepts into concrete records inside Leantime.

This mapping is a working agreement, not a strict conceptual equivalence: a Product Goal is the long-term objective for the product, a Milestone is a staged delivery checkpoint, and an Epic is simply a common way to group large initiatives rather than a formal Scrum artifact. Milestones work well for tracking staged goals, but a progress bar percentage should never replace judgment about actual business value.

In the workflow below, assume we have a single main product workspace where tasks flow across To Do → In Progress → Testing & CR → Done. The Backlog isn’t a separate board column; it’s simply the set of items not yet assigned to a sprint. Keep Testing & CR mapped to an incomplete status category, and only map Done to a completed state. When work is blocked, keep the card in its current column and mark it with a title prefix and tag so you don’t lose sight of where it stalled. Work-in-progress (WIP) limits are maintained collectively by the team.

A practical minimum DoD looks like this: agreed AC verified, peer code review completed and merged, automated checks and necessary regression tests passed, relevant documentation updated, and the increment ready for release. Releases can happen anytime during the sprint—you don’t need to hold finished work until the Sprint Review. Development subtasks should be completed before handing a card over for testing, while QA subtasks are checked off as testing finishes; you don’t need every single subtask checked before moving a card into Testing & CR. Regular feature cards don’t require hourly time logs, and shared support bucket cards don’t get story points—they just record time spent against your reserved buffer.

In Leantime v3.9.8, built-in ticket types are task, subtask, story, and bug. Effort labels XS/S/M/L/XL store numeric values 1/2/3/5/8 (plus 0.5 and 13), and Priority includes an additional Lowest level. We simply agree on which subset to use without modifying Leantime’s code. And remember: the Daily Scrum is for delivery team members to inspect progress toward the Sprint Goal and adjust their plan. The SM facilitates, the PO joins as needed, and it is never a micromanagement task-dispatch session.

From Staged Goals to Daily Collaboration

flowchart LR
    subgraph SG_PLAN["Strategy & Planning Layer"]
        M["Milestones<br/>Product Goal / Epic"]
        B["To-Dos: Backlog View<br/>Product Backlog"]
    end

    subgraph SG_SPRINT["2-Week Sprint Execution Layer (Sprint Container)"]
        S["Sprints Management<br/>W1 Mon ~ W2 Fri"]
        STORY["Parent To-Do: Story/Task<br/>User Story / Engineering Task"]
        BUG["Parent To-Do: Bug<br/>Standalone Defect Card"]
        SUB["Subtasks<br/>Frontend / Backend / Integration / QA"]
    end

    subgraph SG_METRIC["Metrics & Continuous Improvement Layer"]
        BURN["Sprint Dashboard<br/>Burndown & Velocity"]
        RETRO["Blueprints Retro Canvas<br/>Sprint Improvement Items"]
        WIKI["Wiki / Docs<br/>PRD / Architecture ADR / Standards"]
    end

    M -->|Break down & link| B
    B -->|Pull in Sprint Planning| S
    S -->|Contains| STORY
    S -->|Contains| BUG
    STORY -->|Decompose| SUB
    STORY -->|Sum Effort points| BURN
    BUG -->|Sum Effort points| BURN
    S -->|W2 Fri review| RETRO
    RETRO -->|Candidate improvements| S
    WIKI -.->|Link / Bi-directional ref| STORY

What Each Record Type Carries

Clear Responsibilities Without Turning Collaboration into Approval Gates

In a small team, people often wear multiple hats. Separating responsibilities here isn’t about drawing territorial lines—it’s about answering two practical questions: who keeps an eye on this area day to day, and who needs to be in the conversation when we make trade-offs.

The PO maintains backlog order, clarifies business value, and gives timely feedback. The Tech Lead watches over technical risk, and when doubling as SM, focuses on unblocking flow rather than dictating estimates or scope for everyone else. Developers and QA join forces starting from backlog refinement to estimate, break down, and verify the work, while DevOps capacity for environments and releases is planned alongside feature delivery instead of bolted on at the end.

In Leantime, it helps to assign one primary owner to each parent card to keep it moving, while using subtasks to show who is collaborating on specific pieces. Having a single card owner doesn’t mean that person carries the whole delivery alone—and it certainly doesn’t mean everyone else can tune out during code reviews, testing, or blockers.

Instead of building a heavy permissions matrix, a few handoff questions are usually enough to check whether responsibilities are clear:

As long as the Sprint Goal holds, scope can be renegotiated as the team learns more. “Locking” a sprint simply means nobody quietly drops extra work onto the board without a conversation—it doesn’t mean freezing learning. Also keep in mind that these working agreements are team norms, not hard permission restrictions inside Leantime.

Shape Requirements Until They Are Actually Ready to Start

A Kanban board makes current work visible, but it doesn’t automatically explain why the work matters. On one side, you need staged goals so the team doesn’t spend every day swatting disconnected tickets. On the other side, individual cards need enough clarity that developers don’t start coding only to stall halfway through because core rules were never discussed.

I like to separate those two concerns: use Milestones to organize staged outcomes, and use Backlog cards to define what needs to be built and how it will be verified. Backlog refinement bridges the two so Sprint Planning isn’t the first time people see the details.

Use Milestones to Keep Sight of Staged Goals

Epic → Story → Subtask is a popular way to organize requirements, even though Scrum itself doesn’t mandate a three-tier hierarchy. For a small team using Leantime, a Milestone works nicely to group a release or a major feature, with independently testable To-Do cards linked underneath and Subtasks broken out as needed. Keep the long-term Product Goal stated clearly on its own rather than treating Milestone, Epic, and Product Goal as interchangeable words.

How a Release Breaks Down into Everyday Tasks

flowchart TD
    subgraph SG_STRAT["Strategy & Release Layer (Monthly / Quarterly Roadmap)"]
        M1["Milestone 1: [v1.2.0] Unified Auth & SSO Center<br/>(Acts as Epic / Release Goal)"]
        M2["Milestone 2: [v1.3.0] Real-Time Dashboard & Export Engine<br/>(Acts as Epic / Release Goal)"]
    end

    subgraph SG_DELIV["Sprint Delivery Layer (2-Week Sprint / Product Backlog)"]
        S1["To-Do (Story): WeCom QR Login & Account Binding<br/>Sprint S21 | Effort: 5 | Priority: High"]
        S2["To-Do (Story): RBAC Role Permission Admin UI<br/>Sprint S21 | Effort: 8 | Priority: High"]
        B1["To-Do (Bug): Intermittent 401 Loop on Token Refresh<br/>Sprint S22 | Effort: 2 | Priority: Critical"]
        S3["To-Do (Story): Async Report Generation & Streaming CSV Download<br/>Sprint S22 | Effort: 5 | Priority: Medium"]
    end

    subgraph SG_EXEC["Engineering Execution Layer (Daily Standup Granularity: 0.5~1 Day)"]
        T1["Subtask: [Backend] DB user_oauth schema migration"]
        T2["Subtask: [Backend] OAuth2 callback API & JWT issuance"]
        T3["Subtask: [Frontend] Login QR component integration & error states"]
    end

    M1 --> S1
    M1 --> S2
    M1 --> B1
    M2 --> S3
    S1 --> T1
    S1 --> T2
    S1 --> T3

How Much Detail Belongs on a Milestone

At the start of a quarter or before kicking off a major release, the PO opens Milestones in the left navigation and clicks + Add Milestone:

1. Naming convention (a consistent prefix helps):
   • By release version: [v1.2.0] Merchant Settlement Refactor & Automated Reconciliation
   • By business initiative (Epic): [Q4-Epic01] Multi-Tenant Permissions & Audit Logging
2. Planned dates (Plan Dates):
   • Fill in the target Start Date and End Date.
   • Aligning milestone end dates with a Sprint end date (Friday) keeps release checkpoints in sync with iteration boundaries.
3. Color coding:
   • Blue (#1B75BB): Core product features (Feature Release)
   • Purple (#6F42C1): Architecture evolution / infrastructure work (Tech Debt / Infra Epic)
   • Orange/Red (#FD7E14): External compliance or fixed-date commitments (Compliance / Hard Deadline)
4. Dependencies (Depending Milestone):
   • If “v1.3 Settlement Report Export” depends on “v1.2 Core Settlement Engine,” set Depending Milestone to v1.2 so the Gantt view draws the dependency link automatically.

What the Progress Bar Shows—and What It Doesn’t

In Leantime v3.9.8, Milestone completion percentage is calculated from linked tickets: each ticket’s Effort is multiplied by a priority weight factor, and the progress bar shows completed weighted points divided by total weighted points. Tickets missing an Effort or Priority value fall back to defaults. That means the percentage is neither a simple card count, nor a pure story-point completion rate, and certainly not a measure of whether the business outcome was achieved.

1. Open any To-Do detail modal, or edit inline inside the Table View.
2. Select the target release in the Milestone dropdown.
3. Once saved, the ticket’s Effort, Priority, and status category feed into that Milestone’s progress bar. Never tweak priorities or story points just to make the progress bar look prettier. Also note that if both parent cards and subtasks are linked to a milestone, both can affect the calculation—so don’t use this percentage as your team velocity.
4. Use the timeline to ground conversations: When reviewing release plans across teams, projecting Milestones -> Timeline is a handy way to show date ranges, dependencies, and rough progress, as long as you still explain the real risks and changes behind the numbers.

Use a Definition of Ready (DoR) to Cut Down on Mid-Sprint Stalls

“Build an export feature” is a fine starting point for a conversation, but it’s not ready for sprint execution. Who uses it, which columns get exported, how large the dataset can get, and what happens on failure will all shape coding and testing. Clarifying those questions upfront prevents developers from stalling mid-sprint—not to create bureaucracy, but to reduce waiting.

A Definition of Ready (DoR) works best as a lightweight checklist for the team rather than a rigid gate mandated by Scrum. You don’t need to eliminate every unknown before starting; when something genuinely can’t be answered upfront, run a small timeboxed spike first.

A Readiness Checklist You Can Adapt by Ticket Type

For cards near the top of the backlog that are candidates for the next sprint, check these six areas. UI work needs design links, while pure backend or infrastructure tasks obviously don’t need a dummy mockup link just to check a box.

Walking Through a Story Template with a CSV Export Example

Below is a full User Story template using a transaction export feature as an example. The specific thresholds and architecture notes are illustrative—for simpler stories, keep only the sections that help. Pinning this template in the project Wiki makes it easy to copy into new To-Do descriptions.

### 1. User Story

- **As a**: [Specific user role, e.g., Finance Reconciliation Specialist / Platform Ops Admin]
- **I want**: [Core action, e.g., filter transaction records by month and channel and export them to a CSV file]
- **So that**: [Business value or pain point solved, e.g., cut monthly manual bill reconciliation from 4 hours to under 10 minutes]

---

### 2. Context & Design Assets

- **Background / Wiki Deep Link**: [Brief context, or link to the full spec in Leantime Wiki]
- **UI / Prototype Link**: [Figma / prototype link with version note]
- **Core Business Rules**:
  1. A single export can span at most 92 days (3 months); block and prompt on the frontend if exceeded.
  2. Format monetary amounts to two decimal places and put currency symbols in the column header rather than individual cells.
  3. Only roles with the `finance:export` permission can see the "Export" button.

---

### 3. Technical Constraints & API Notes

> _(Added by the Tech Lead or lead developer before/during refinement)_

- **Services / Modules Involved**: `order-service`, `report-worker`, `admin-web`
- **Key Approach & Constraints**:
  - Exports over 10,000 rows go through an async queue (Redis + Worker), upload to object storage (OSS), and notify the user via in-app message.
  - Reuse the filter payload from `/api/v1/orders/query` and add an async endpoint `/api/v1/orders/export-tasks`.
- **External Dependencies / Risks**: Ops needs to configure a 7-day auto-expiration lifecycle rule on the production OSS temp export bucket ahead of release.

---

### 4. Acceptance Criteria (AC)

> _(Shared baseline for QA verification and DoD completion)_

- [ ] **AC1 (Normal flow - sync / small dataset)**: When filtered results are <= 10,000 rows, clicking "Export CSV" triggers a direct browser download within 3 seconds, named `settlement_records_YYYYMMDD_HHMM.csv`.
- [ ] **AC2 (Normal flow - async / large dataset)**: When filtered results exceed 10,000 rows, clicking shows "Generating report; you will be notified via in-app message when ready," and background generation finishes within 60 seconds on a 100k-row benchmark dataset.
- [ ] **AC3 (Data accuracy)**: Total row count and net amount sum in the CSV match the summary cards at the top of the list view, and UTF-8 BOM encoding prevents garbled non-ASCII characters in Windows Excel and WPS.
- [ ] **AC4 (Edge & empty states)**: When the selected date range exceeds 92 days or returns 0 rows, disable the "Export CSV" button and show the reason on hover.
- [ ] **AC5 (Permissions & docs)**: Calling the export API without `finance:export` returns `403 Forbidden`; new config keys are documented in the Leantime Wiki.

Bug Cards Should Make Reproduction Effortless

For a standalone Bug card (Type = Bug), what matters most isn’t bureaucratic formatting—it’s whether someone else can reproduce the issue and judge its impact quickly. The template below captures symptom summary, repro steps, expected vs. actual results, and environment evidence (all IDs and logs shown are sample data):

### 1. Defect Summary

- **Module**: [e.g., Mobile Checkout - Coupon Discount Calculation]
- **Severity**: [Critical / Major / Minor / Trivial — describes impact scope]
- **Fix Priority**: [Critical / High / Medium / Low — decided by impact, urgency, and available workarounds; not automatically identical to Severity]
- **Related Story**: [Link or ID of the related User Story To-Do, e.g., #142]

---

### 2. Steps to Reproduce

1. Log into Staging with test account `test_vip_01`.
2. Add SKU `10086` (unit price $100.00, quantity 2) to the cart and open checkout.
3. Select the "$30 off orders over $200" store coupon, then manually reduce item quantity to `1`.
4. Click "Pay Now" at the bottom and observe the UI and network response.

---

### 3. Expected vs. Actual Result

- **Expected**:
  - After reducing quantity to 1 (total $100 < $200 threshold), the system automatically unchecks the coupon, updates the payable amount to `$100.00`, and opens the payment sheet normally.
- **Actual**:
  - The page still displays `$70.00` as the payable amount; clicking "Pay Now" shows no UI error, while the console logs a `500 Internal Server Error`.

---

### 4. Environment & Evidence

- **Environment**: `Staging (v1.2.0-rc2)` | **Client**: `iOS 17.4 / WeChat Built-in Browser 8.0.48`
- **Test Account / Data ID**: `UserID: 99201` / `CartID: c_8839201`
- **Network Trace / Logs / Screenshot**:
  - Request URL: `POST /api/v1/checkout/submit` | TraceID: `7f8a9d10-3b2c-4e1a-9f00-123456789abc`
  - Error summary: `CouponDiscountExceedsThresholdException: coupon 4021 requires min_amount 20000, actual 10000`
  - _(Paste screenshot or screen recording here)_

Clarify Requirements Before Sprint Planning

When a team sees new requirements for the first time during Monday’s Sprint Planning, scope selection, requirement clarification, and technical design all collide into a three-hour marathon. Running a short mid-sprint backlog refinement session clears up questions on upcoming candidates ahead of time so Sprint Planning can stay focused on goals, capacity, and trade-offs.

Leave Time for Follow-Ups, and Don’t Force Everyone to Sit Through Edge Cases

• Timing: Hold refinement on Tuesday afternoon of Week 2 (15:00 - 15:45) (or Thursday afternoon of Week 1). That leaves roughly three working days before next Monday’s Sprint Planning for the PO and Tech Lead to fill in missing design details or run quick technical checks.
• Duration: Keep it to 30 to 45 minutes. If a single card still has open questions after 8 minutes, park it for a focused follow-up after the meeting.
• Participants: The PO, developers, and QA who will build and test the work review the upcoming candidates together, while the Tech Lead highlights architectural risks. In an 8-person team everyone can join, but deep-dive topics don’t need to hold the entire room hostage—and refinement won’t magically eliminate every unknown.

Using Leantime’s Table View to Refine Candidates Together

During refinement, switching To-Dos -> Table makes it easy to sort priorities and edit fields inline. A typical session flows through five quick steps (timings are rough guides):

1. Step 1: Filter the view to focus on unscheduled work (1 min)
   • Open To-Dos in Table view, filter Sprint to Backlog, and sort by Priority.
2. Step 2: Calibrate priorities and archive stale cards (5 min)
   • The PO scans the top 15 to 20 backlog items and adjusts Priority inline (Critical \rightarrow High \rightarrow Medium \rightarrow Low). Low-priority wishes that have sat untouched for months with no clear value can be closed or archived on the spot.
3. Step 3: Walk through context and align on AC (15 to 20 min)
   • Starting from the top unestimated High-priority card, the PO takes two minutes to walk through context and AC. Developers and QA poke at data compatibility, performance bottlenecks, edge cases, and idempotency.
   • Update the card live: Any newly agreed edge cases or AC adjustments get typed directly into the card’s Description and saved during the meeting.
4. Step 4: Quick Fibonacci estimation and splitting oversized cards (10 min)
   • Count down “3, 2, 1” and have developers and QA post Fibonacci numbers (1, 2, 3, 5, 8, 13) in chat or hold up fingers simultaneously.
   • If estimates match closely, enter the value into the Effort column. If they diverge widely (say, a 2 and an 8), the lowest and highest estimators each take 30 seconds to explain their reasoning before re-estimating.
   • Any card landing at 13 points or above gets split into smaller \le 8-point stories by business step, or preceded by a 2-point technical spike.
5. Step 5: Check whether you have enough ready candidates (2 min)
   • Filter Table View to Ready cards that meet DoR and sum their Effort values manually (don’t assume the table header automatically totals filtered story points).
   • Ready buffer guideline: If your team historically finishes around 40 SP per sprint, having roughly 60 SP of Ready candidates gives you room to make trade-offs during planning. Note that 40 SP is purely an example, not a benchmark for every 8-person team—and there’s no need to over-polish distant backlog items just to hit a number.

Tying Daily Collaboration Together Across a Two-Week Sprint

Once upcoming stories are reasonably clear, the next challenge is keeping work flowing smoothly across the sprint rather than just stuffing a bucket of tasks into a two-week container. Using Sprint 2026-S21 as a concrete walkthrough, here is how planning, coding, code review, testing, and review connect across ten working days.

The calendar below isn’t a rigid script for every hour of the week. Its real job is to highlight a common failure mode: if everyone codes in isolation during Week 1 and dumps everything on QA on Thursday of Week 2, a two-week sprint turns right back into a mini-waterfall.

A Sprint Calendar Exists to Remind Us to Hand Work Over Early

It helps to agree upfront that a batch of stories should enter review and testing during Week 1, and that by mid-Week 2 the team checks whether large items are still unsubmitted. The table below uses “roughly 30% of stories entering verification by Week 1 Thursday” and a “Week 2 Wednesday check on remaining unsubmitted feature work” as practical pacing reminders—not quotas that people game by dragging unfinished cards across columns. Over the long run, shrinking story size, involving QA earlier, and cutting review wait times matter most.

Sample Two-Week Cadence

gantt
    title 8-Person Team 2-Week Sprint (10 Working Days) Cadence
    dateFormat  YYYY-MM-DD
    axisFormat  %m-%d
    excludes weekends
    section Agile Ceremonies
    Sprint Planning (<=60m)         :milestone, m1, 2026-11-02, 0d
    Daily Standup (15m daily)       :active, d1, 2026-11-02, 10d
    Next Sprint Grooming (<=45m)    :milestone, m2, 2026-11-10, 0d
    Review & Retro (60m)            :milestone, m3, 2026-11-13, 0d
    section Dev & QA Flow
    Coding & Unit Tests (Main)      :dev1, 2026-11-02, 8d
    First 30% to QA (W1 Thu)        :crit, milestone, c1, 2026-11-05, 0d
    Continuous QA & Peer CR         :cr1, 2026-11-04, 7d
    Feature Code Freeze (W2 Wed)    :crit, milestone, c2, 2026-11-11, 0d
    Bug Convergence & Regression (W2 Thu) :qa1, 2026-11-12, 1d

Start Sprint Planning from the Goal and Realistic Capacity

Time window: W1 Monday 09:30 - 10:30 (kept under 60 minutes assuming backlog refinement happened the previous week).
Facilitator: Tech Lead / Scrum Master (SM).
Core objective: Work out realistic team capacity, select sprint scope, break down subtasks, and align on the Sprint Goal.

Calculate Available Time Before Talking About Story Points

“One person over two weeks equals ten working days” never means ten full days of feature coding. Meetings, time off, and recurring responsibilities all take time, and bottlenecks between development, code review, and QA matter just as much as raw headcount. Capacity planning is about making those constraints visible rather than producing a false sense of precision.

A Practical Way to Estimate Available Capacity

Taking the seven delivery members outside the PO as an example, estimate available time per person first and sum it up:

C_{\text{plan}} = \sum_{i=1}^{7} (D_i - L_i - M_i - F_i) \times (1 - B)

Every time term is measured in person-days: D_i is actual working days in the sprint, L_i is planned leave, M_i is scheduled meeting time, and F_i covers fixed non-sprint duties; B is the buffer ratio reserved for unplanned support and urgent fixes (starting around 15% to 20%). Deduct each responsibility only once. Code review, integration, and testing are core delivery activities—don’t subtract them from capacity and include them again in story estimates.

In this guide, Sprint Planning, 10 daily standups, refinement, Review, and Retro add up to roughly 5.25 hours—about 0.66 person-days on an 8-hour day, rather than a flat 10% rule of thumb. Adjust for any other recurring company meetings your team attends.

Keep Person-Day Constraints Separate from Historical Story-Point Forecasts

Story points estimate relative effort, complexity, and uncertainty for delivering a whole story end to end. They do not convert at a fixed ratio to person-days, and they should never be assigned as individual quotas. When a team is just starting out, pick a modest set of ready stories, break them into subtasks, and check whether development, CR, and QA capacity can realistically absorb them instead of trying to pack the board to match an arbitrary point target.

Once the team has completed three or more comparable sprints, you can use the rolling average of completed parent-card story points as a rough reference:

V_{\text{ref}} = V_{\text{avg3}} \times \frac{C_{\text{current}}}{C_{\text{avg3}}}

Use the exact same deduction rules in both the numerator and denominator. If historical capacity already accounted for your support buffer, don’t multiply by another 80% to 85% a second time. Treat this number as a reference forecast rather than a hard guarantee, and still check for key-person absences or QA bottlenecks. All 1/2/3/5/8 estimates are sized relative to historical anchor stories, with 8 points as our trial cap for a single card.

Turning Candidate Stories into an Executable Sprint Plan

Step 1: Create the Sprint and Set Up Shared Support Bucket Cards (09:30 - 09:35, 5 min)

1. Facilitator: Tech Lead / SM.
2. Path: In the current Leantime project \rightarrow top nav To-Dos \rightarrow top-left Sprint dropdown \rightarrow + Add Sprint / Manage Sprints.
3. Naming & dates:
   • Sprint name: Sprint YYYY-S## (MM.DD-MM.DD), e.g., Sprint 2026-S21 (11.02-11.13).
   • Start Date: 2026-11-02 (W1 Mon); End Date: 2026-11-13 (W2 Fri).
4. Create shared support bucket cards: Create [Sprint-S21] Production Triage & Daily Ops Support Bucket in the new sprint (covered in the operational support section below) and assign the week’s on-call developer (Batman).

Step 2: Pull High-Priority Stories from the Backlog in Table View (09:35 - 09:50, 15 min)

1. Switch view: In the top-right corner of To-Dos, switch from Kanban to Table / List View and filter Sprint to Backlog.
2. Double-check readiness (DoR): The PO walks down the prioritized list (Critical \rightarrow High \rightarrow Medium), confirming each candidate story meets DoR (including any candidate [Retro Improvement] tasks from the previous Friday).
3. Assign to the sprint:
   • In the table row’s Sprint dropdown, change Backlog to Sprint 2026-S21 (11.02-11.13).
   • As each card comes in, delivery members check total Effort, dependencies, and dev/QA balance, stopping once capacity is full. Again, 40 SP is just an example number, not a universal cap. Propose a draft Sprint Goal before selecting stories, then confirm it together at the end.

Step 3: Claim Parent Stories and Break Down Subtasks (09:50 - 10:20, 30 min)

A parent card tells you what needs to be delivered; subtasks make it obvious what still needs to happen to get it done. Breaking work into subtasks is about exposing dependencies and coordinating handoffs, not turning every line of code into a ticket.

1. Assign a primary Story Owner:
   • Switch back to the board or list view for Sprint 2026-S21.
   • Set Assigned To on each parent Story to one primary developer (Story Owner). Even when a story spans frontend and backend, having one person shepherd it through integration and testing prevents diffused responsibility.
2. Break down Subtasks (aiming for 0.5 to 1 day per item):
   • Team members open their stories and switch to the Subtasks tab.
   • Break out the necessary frontend work, backend APIs, integration testing, schema changes, and QA test design/execution into distinct subtasks.

• Granularity guideline: Half a day to a day (4 to 8 hours) of collaborative work is a good rule of thumb, usually resulting in 3 to 6 subtasks per normal story. Don’t pad small tasks just to hit a minimum count, and if a tiny story only takes one person a couple of hours, don’t invent subtasks for ceremony’s sake.

[Example] Subtask breakdown for parent card #123 [Story] Monthly Corporate Bill PDF Export & Async Email Delivery (5 SP):

• [Contract] Define OpenAPI spec for bill export and confirm across FE/BE — Owner: Dev A | Est: 4h
• [Backend] Implement PDF template rendering & temporary OSS signed upload — Owner: Dev A | Est: 8h
• [Backend] Wire up async message queue & email retry notification logic — Owner: Dev A | Est: 6h
• [Frontend] Add export filter modal & polling progress bar on bill list page — Owner: Dev B | Est: 6h
• [Integration] End-to-end self-test for export trigger, limit warnings & download flow — Primary: Dev A, Collab: Dev B | Est: 4h
• [QA] Write boundary test cases for bill export and run integration verification — Owner: QA C | Est: 6h

Step 4: Confirm and Record the Sprint Goal (10:20 - 10:30, 10 min)

1. Distill a concise goal: The PO and team summarize the core business outcome of the sprint in one or two sentences, rather than listing ticket IDs.
   • ❌ Weak example: “Finish development and testing for cards #123, #124, #128, and #130.” (That’s a task list, not a goal.)
   • ✅ Better example: “Deliver self-service monthly billing for corporate customers (generation, PDF export, and email delivery) to cut manual finance billing support tickets.”
2. Record it in Leantime: Write the goal into a Wiki page named Sprint 2026-S21 Goal & Review Notes and link it from the relevant cards so you don’t depend on a specific dashboard widget. Judging whether a goal succeeded requires observable outcomes; a target like “cut support tickets by 80%” needs a baseline and post-release observation, not a victory declaration during the sprint demo.

Run Daily Standups Around the Board, Not Individual Status Reports

Hold a fixed 15-minute daily session where delivery members open the current sprint’s Kanban board, inspect progress toward the Sprint Goal, and coordinate the day’s plan. Whether people stand or who shares their screen doesn’t matter; deeper technical debates happen right after with only the relevant people.

Walk the Board Right-to-Left: Focus on Finishing First

Asking “What did I do yesterday, what will I do today, and what’s blocking me?” isn’t inherently bad, but going around the room person by person makes it easy to miss how the work connects:

1. Turns into a status report to management: Once people finish their turn, they tune out instead of noticing where a teammate’s card is stuck.
2. Hides piles of half-finished work (runaway WIP): Developers say “still working on module X” every day until Week 2 Wednesday arrives and five stories are sitting at 80% done with nothing in QA.
3. Rewards starting over finishing: People naturally grab fresh cards from To Do instead of reviewing a teammate’s PR or fixing a bug blocking a card in Testing & CR.

Walking the board right-to-left flips the conversation order: inspect the cards closest to Done first, then look at In Progress, and only then talk about pulling new work from To Do. That keeps focus on clearing bottlenecks and finishing work in flight—though it never overrides genuine production emergencies or means you must keep pouring effort into something that lost its business value.

flowchart RL
    subgraph SG_BOARD["Leantime Kanban Standup Order (Right to Left)"]
        direction RL
        D["Done<br/>(Accepted this sprint)"]
        T["① Testing & CR<br/>(Priority 1: Unblock CR, QA & bug fixes)"]
        P["② In Progress<br/>(Priority 2: Check subtask progress & clear blockers)"]
        TODO["③ To Do<br/>(Priority 3: Pull new cards only when WIP allows)"]

        D -.->|Focus on work closest to completion| T
        T -->|Keep existing work flowing| P
        P -->|Respect WIP limits before pulling| TODO
    end

Three Stops Across the Board

When reviewing the board together, move across Testing & CR → In Progress → To Do:

Stop ①: Testing & CR Column (~5 min)

• Key question: Can this card move to Done today? Is it waiting on code review, test environment state, or a bug fix?
• Immediate coordination:
  • If a PR is waiting on review, confirm who can review it and when they can give feedback, adjusting other work if needed.
  • If QA found a defect on an in-flight story, agree on its impact and fix order so nearly finished stories don’t sit neglected while new cards get started.

Stop ②: In Progress Column (~7 min)

• Key question: Which subtasks are complete, how far is the story from testing, and are any frontend/backend handoffs blocked?
• Immediate coordination:
  • Expand the card’s Subtasks view during the check-in and check off any subtasks finished yesterday if the owner forgot.
  • Check WIP limits: In a team with 4 to 5 developers, keeping total In Progress parent stories around 5 to 6 cards (roughly 1 to 2 active stories per developer) prevents thrashing. If someone has 3 or 4 stories open at once, pause the untouched ones and focus on finishing one first.
  • Aging card alert: If a card sits in In Progress for more than 3 working days without subtask movement, flag it as blocked and see what help it needs.

Stop ③: To Do Column & Burndown Check (~3 min)

• Key question: Who is wrapping up current work today and ready to pull the next card from To Do? Are prerequisites (designs, third-party APIs) ready?
• Immediate coordination: Confirm pairing or integration counterparts for newly started cards, glance at the Sprint Burndown trend, and wrap up on time.

Mark Blockers Clearly and Take Deep Dives Offline

Ninety percent of standup overruns happen because two engineers start debugging an implementation detail live, or a developer and the PO debate an edge-case interaction while six other people stand around listening. A simple “10-second blocker tag + 5-minute post-standup huddle” keeps the main meeting crisp:

1. Tagging a blocker in 10 seconds
   • Action: Leave the card in its current column (e.g., In Progress), prefix the title with [🔴Blocked], add the Blocked tag, and note who owns the next step and when to re-check. Don’t automatically bump business Priority to Critical—being blocked and being highest business priority are two separate dimensions.
   • Note: Drop a one-line comment in Discussion with the reason and owner, e.g., 2026-11-05 standup: WeChat Pay sandbox cert expired, blocking integration; @TL following up with Ops before 14:00 today.
2. Post-standup huddle (10:15 - 10:20)
   • Let uninvolved teammates get back to work: When standup ends at 10:15, anyone not needed for the blocker discussion heads right back to their day.
   • Bring together only the relevant people: Technical snags are hashed out by the developers and QA involved, bringing in the PO when scope or business rules are affected. You can trim non-essential scope, pair up on a hard problem, or schedule a dedicated design session without forcing a rushed decision in five minutes.

Coding Done Is Only Half the Journey

On a Kanban board, “in progress” really spans coding, waiting for review, deployment, and verification. Keeping branch links and handoff notes on the card lets everyone see what a story is waiting on without asking around.

flowchart TD
    START(["Pulled in Sprint Planning"]) --> ToDo["To Do / Sprint Backlog"]
    ToDo -->|Claim card & create feat/LT-ID branch| InProgress["In Progress / Development"]
    InProgress -->|Dev subtasks done, PR opened & self-tested| TestingAndCR["Testing & CR / Review & Verification"]

    subgraph SG_VERIFY["Collaboration Inside Testing & CR"]
        direction LR
        CodeReview["TL / Peer completes CR & merges to test env"] --> QAVerify["QA runs acceptance verification"]
    end

    TestingAndCR -.-> SG_VERIFY
    TestingAndCR -->|Track 1: In-story defect<br/>Add Bug Subtask on story & return| InProgress
    TestingAndCR -->|All AC met & Wiki updated| Done(["Done / Completed"])

    subgraph SG_BUG["Track 2: Standalone / Regression / Prod Defect"]
        NewBugCard["Create standalone Type=Bug card"]
    end

    NewBugCard -->|Assign to current Sprint buffer or Backlog| ToDo

Keep Code and Cards Traceable to Each Other

Including the Leantime ticket ID (the #number shown at the top-left of a card, like #123) in branch names, commits, and PRs makes tracing changes effortless. The patterns below are examples—if your repo already has working conventions, keep them and simply link the card and PR:

1. Git branch naming examples:
   • Feature branch: feat/LT-123-monthly-bill-pdf
   • Standalone bugfix branch: fix/LT-156-token-refresh-race
   • Chore / refactor branch: chore/LT-140-ci-docker-cache
2. Commit messages & PRs:
   • Commit format: feat(billing): add async pdf generation worker (Ref #123)
   • PR / MR title: [LT-123] Monthly Corporate Bill PDF Export & Async Email Delivery
   • Paste the Leantime card URL at the top of the PR description, and drop the PR link into the Leantime card’s Discussion tab.

Hand Over Context When Moving a Card to Testing & CR

Moving a card into Testing & CR should mean it is genuinely ready for review and verification, not just “I finished typing the code.” Walking through the main path yourself and leaving clear notes on the environment, PRs, config changes, and regression impact saves QA from having to hunt down basic context.

We start with four handoff checks before dragging a card from In Progress to Testing & CR (these are entry checks for verification, not a replacement for the final DoD):

1. Development subtasks checked off: Open the card’s Subtasks tab and confirm [Contract], [Frontend], [Backend], and [Integration] items are complete.
2. PR/MR opened and verifiable in an isolated environment: CI build, linter, and unit tests pass. Prefer isolated PR preview environments where possible; if the team shares a single Staging environment, complete code review and merge before deploying to Staging for QA so unreviewed code doesn’t overwrite shared test state.
3. Happy path & quick desk check completed: The Story Owner has walked through the AC in the test environment (for complex UI flows, a 3-minute screen-share desk check with QA works wonders).
4. Handoff & self-test note posted in Discussion: Paste a brief handoff note in the card’s Discussion tab and @mention the reviewer and QA:

📋 Sample Handoff & Self-Test Note in Leantime Card Comments

• [Environment & Branch]: Staging | Branch: feat/LT-123-monthly-bill-pdf
• [PR Links]: Backend PR #408 / Frontend PR #215 (@TechLead ready for CR)
• [Config / DB Changes]: Applied V20261105__add_bill_export_task.sql; added Redis config BILL_EXPORT_TTL=3600
• [Self-Test Check]:
  • AC1: Export triggers for any selected month within the last 12 months (verified)
  • AC2: Datasets over 10,000 rows switch to async background generation + notification (verified with test account corp_test_01)
  • AC3: Months with no bills display a clean empty-state prompt (verified)
• [Impact & Regression Notes]: Touched shared MailSender component; recommend regression-checking the “Password Reset Email” flow. Ready for @QA_C.

Deciding When a Bug Needs Its Own Card

Defects found during testing generally fall into two buckets: unfinished details on an in-flight story stay as subtasks on that story, while cross-module regressions, production escapes, or issues needing independent tracking get their own Type = Bug card. The goal is clear traceability, not artificially minimizing bug counts.

Two Ways to Record Defects

If a small defect needs separate audit tracking or has to be deferred independently, go ahead and create a standalone Bug card linked to the story. Traceability always comes before keeping card counts tidy.

Sprint Review Inspects Outcomes, Retro Inspects How We Work

Sprint Review and Sprint Retrospective can run back-to-back on Friday afternoon of Week 2, but they answer different questions: Review inspects the product increment, goal progress, and next steps with stakeholders, while Retro looks at how the team collaborated. Below is a 60-minute example (30 minutes each); if discussions need more room, adjust the schedule rather than rushing feedback just to fit the clock.

flowchart LR
    subgraph SG_REV["Part 1: Sprint Review (16:00 - 16:30)"]
        R1["16:00-16:05<br/>Review Sprint Goal & Burndown<br/>Inspect planned vs. completed scope"] --> R2["16:05-16:25<br/>Live Demo of Done Increments<br/>Walk through working software against AC"]
        R2 --> R3["16:25-16:30<br/>Handle Unfinished Cards<br/>Re-evaluate in Backlog for next planning"]
    end

    subgraph SG_RET["Part 2: Sprint Retro (16:30 - 17:00)"]
        T1["16:30-16:35<br/>Silent Card Writing (5m)<br/>Fill in Continue / Stop / Start"] --> T2["16:35-16:45<br/>Group & Vote (10m)<br/>2 votes per person to pick top 1~2 pain points"]
        T2 --> T3["16:45-16:55<br/>Root Cause & Countermeasures (10m)<br/>Derive concrete engineering actions"]
        T3 --> T4["16:55-17:00<br/>Create Candidate To-Do Cards (5m)<br/>Assign Owner & confirm in next planning"]
    end

    R3 --> T1

Sprint Review Is More Than a Card-by-Card Demo

A good Sprint Review focuses on real outcomes and stakeholder feedback. Demonstrate increments that actually met DoD, and be upfront about what didn’t finish and what changed along the way—unfinished work shouldn’t be dressed up as delivered. Whether you use slides or not isn’t the point; what matters is inspecting working software rather than putting on a presentation.

1. Review the Sprint Goal and burndown snapshot (16:00 - 16:05, 5 min)
   • Show the current Sprint Burndown alongside the scope snapshot recorded during Sprint Planning, separating goal outcomes, completed stories, and mid-sprint additions or removals. Finishing 38 SP out of an initial 40 SP is simply a scope completion ratio, not automatic proof that the Sprint Goal succeeded. Discuss actual outcomes, market or technical changes, and what should happen next with stakeholders.
2. Live demonstration from the Done column (16:05 - 16:25, 20 min)
   • Demonstrate increments from the Done column that have met DoD, and openly note any unfinished items and their risks without counting them as completed delivery.
   • Each Done card’s Story Owner (or verifying QA) walks through the live feature in Staging or Production against its AC.
   • If the demo sparks new non-blocking enhancement ideas, log them as fresh To-Do cards in the Backlog on the spot without revoking Done on a story that already met its agreed AC.
3. Handling unfinished cards (Carry-over) (16:25 - 16:30, 5 min)
   • Re-evaluate rather than auto-roll: Unfinished stories return to the Backlog to re-check their priority and remaining effort. They can be flagged as candidates for Sprint 2026-S22, but whether they enter the next sprint is still decided together during next Monday’s Sprint Planning.
   • Story point accounting: Any story that didn’t meet DoD counts as 0 SP for the current sprint. Record the sprint’s initial scope, completed items, and carry-overs in the Sprint Wiki before changing the card’s Sprint field so you don’t lose historical context. When the story finishes in a later sprint, count its original story points once in that sprint, while sizing capacity during planning based only on the remaining work—no partial point splitting and no double deductions. If carry-overs happen frequently, treat that as a signal to split stories smaller.

Leave the Retrospective with One or Two Improvements You Can Actually Track

A retrospective needs psychological safety so people focus on systems and processes rather than blaming individuals. Instead of walking away with a long wish list that nobody follows up on, pick one or two concrete experiments, assign a clear owner and completion criteria, and check whether they actually helped in the next retro.

1. Open the retro canvas and write cards silently (16:30 - 16:35, 5 min)
   • In Blueprints, create a canvas using the retros template named Sprint 2026-S21 Retro and link it in the Sprint Wiki. Because it’s a project-level canvas rather than something automatically bound to a sprint dropdown, naming and linking it keeps things organized. Everyone silently adds cards across the three columns:
     • 🟢 Continue: Which engineering or collaboration practices worked well this sprint?
     • 🔴 Stop Doing: Which friction points, handoff stalls, or environment issues slowed us down?
     • 🔵 Start Doing: What concrete change should we try next sprint?
2. Group duplicates and vote on the top 1 to 2 pain points (16:35 - 16:45, 10 min)
   • After merging duplicate notes, each team member gets 2 votes (you can simply tally votes in card comments without needing a voting plugin). Narrow the discussion to the top 1 or 2 pain points.
3. Dig into root causes and agree on concrete actions (16:45 - 16:55, 10 min)
   • Use 5 Whys to turn vague complaints into verifiable workflow or engineering changes, avoiding empty resolutions like “be more careful next time” or “communicate better”:

4. Turn actions into candidate To-Do cards for next sprint (16:55 - 17:00, 5 min)
   • Create 1 to 2 Type = Task cards prefixed with [Retro Improvement], assign an owner, completion criteria, and target date, and place them in the Backlog as candidates for Sprint 2026-S22. Confirm capacity and pull them in during Monday’s Sprint Planning, then review whether they worked at the start of the next retro.

Keep Knowledge Alive Beyond Closed Cards

Once a sprint wraps up, cards fade into the archive—but API contracts, architectural trade-offs, and release caveats keep shaping future work. If that context only lives inside the heads of whoever happened to be in the room, the team will keep paying a tax in repeated explanations.

That’s why I like pairing Leantime’s Wiki with task cards: cards capture what we are executing this sprint, while the Wiki preserves knowledge that stays useful across sprints. Maintaining docs takes real effort; the goal is to spend a little time upfront so future teammates don’t have to rediscover everything from scratch.

Where Docs Live Matters Less Than Finding Them and Keeping Them Current

Using multiple documentation tools isn’t automatically a problem. The real trouble starts when nobody knows which doc is authoritative, links break, or code changes while the docs stay frozen in last year’s design. If your team already has a well-maintained external wiki, keeping stable entry links and bi-directional references is plenty—you don’t need to migrate everything just for purity.

Putting docs inside Leantime’s Wiki / Docs module is simply one convenient option that keeps project knowledge close to the work, provided ownership is clear:

flowchart LR
    subgraph SG_WIKI["Integrated Leantime Knowledge Loop"]
        A["Product Vision & Milestones"] -->|Break down specs| B("Leantime Wiki<br/>PRD / ADR / Runbooks")
        B <-->|Deep-link bi-directional ref| C("Sprint To-Do Cards<br/>Implementation / AC")
        C -->|Updated via DoD check| B
    end

Start with a Small Set of Folders People Actually Use

Leantime’s Wiki / Docs supports hierarchical article trees. Below is a 5-folder starter structure covering onboarding, product specs, architecture decisions, APIs/schemas, and release runbooks. In practice, start with the two or three folders your team hits every week rather than creating an elaborate empty tree on day one.

📚 Project Wiki Root
├── 📂 01-Onboarding & Local Setup
│   ├── 📄 Team Working Agreements & Agile Calendar (Standup / Grooming / Review / Retro)
│   ├── 📄 Half-Day Local Dev Setup Guide (Middleware, Hosts & .env templates)
│   └── 📄 Git Branching Strategy & Commit Conventions (with Story & Bug templates)
├── 📂 02-Product Specs & Prototypes (PRD & Specs)
│   ├── 📄 Domain Glossary (Ubiquitous Language)
│   ├── 📄 [v1.2.0] User Center & Permissions Spec + Prototype Links
│   └── 📄 [v1.3.0] Order State Machine & Refund Exception Rules
├── 📂 03-Architecture & Technical Decisions (ADR & Architecture)
│   ├── 📄 System Architecture Overview & Service Boundaries
│   ├── 📄 ADR-001: Why We Chose PostgreSQL Over Sharded MySQL
│   └── 📄 ADR-002: Async Message Queue Selection & Idempotent Retry Design
├── 📂 04-API Contracts & Database Schema (API & Schema)
│   ├── 📄 Global API Conventions (Response envelope, error codes, auth headers)
│   ├── 📄 Core Table Schemas & Index Change Log
│   └── 📄 Third-Party Integration Sandbox Notes (Sanitized)
└── 📂 05-Runbooks & Release Checklists
    ├── 📄 Dev / Staging / Prod Environment Topology & Resource Inventory
    ├── 📄 Production Release Checklist & Rollback Runbook
    └── 📄 Common Incident Playbooks (DB lockups, third-party timeouts & fallbacks)

Who Keeps Each Folder Alive

• 01-Onboarding & Local Setup: Created by the Tech Lead, and updated by the newest developer or QA whenever they hit outdated steps during onboarding. A good litmus test: can a new engineer get frontend and backend services running locally and complete a test API call within half a day without having to ask around?
• 02-Product Specs & Prototypes: Maintained by the PO, organized by milestone release or core domain.
• 03-Architecture & Technical Decisions: Maintained by the Tech Lead and core developers, focusing on why a choice was made so the team doesn’t relitigate or step into the same trap six months later.
• 04-API Contracts & Database Schema: Maintained primarily by backend developers and referenced by frontend and QA. If you already generate OpenAPI/Swagger docs automatically, just keep global conventions, core ER diagrams, and links to the live API docs here.
• 05-Runbooks & Release Checklists: Maintained by QA/DevOps and the Tech Lead to keep releases predictable.

Sample Template 1: Lightweight Architecture Decision Record (ADR)

When the team settles on a meaningful technical choice—picking middleware, refactoring core tables, or adding a third-party dependency—recording a short ADR under 03-Architecture & Technical Decisions preserves the context. Keep the template concise; how long the underlying engineering discussion takes should depend on the problem’s complexity, not an arbitrary timer.

# ADR-[ID]: [One-line summary, e.g., Adopt Redis for Distributed Sessions and Hot Caching]

- **Status**: Accepted (Proposed / Accepted / Deprecated / Superseded by ADR-XXX)
- **Date**: 2026-MM-DD
- **Participants**: @[Tech Lead] @[Dev A] @[Dev B]
- **Related Ticket**: #[To-Do ID]

## 1. Context & Problem

_Briefly describe the business or system problem and our real-world constraints (e.g., 8-person team, limited ops bandwidth, target delivery within the current sprint)._

- Problem / Symptom:
- Constraints:

## 2. Options Considered

_List the 2 to 3 options discussed and their core trade-offs._

- **Option A (Chosen)**: [Brief summary]
  - Pros:
  - Cons / Risks:
- **Option B (Rejected)**: [Brief summary]
  - Reason for rejection:

## 3. Decision

_State the chosen approach, component versions, and key configuration policies._

## 4. Consequences & Follow-Ups

_Positive outcomes, accepted technical debt, and modules or scripts that need updating._

- **Positive impact**:
- **Trade-offs / Tech debt**:
- **Follow-up changes**: Update deployment scripts / add env var `XXX`

Sample Template 2: Production Release Checklist

Releases don’t have to wait for the end of a sprint. The checklist below is a sample starting point—adapt the steps, migration order, and rollback plan to fit your actual architecture rather than treating the sequence below as a universal script.

# [Version, e.g., v1.4.0] Production Release Checklist

- **Release Date**: 2026-MM-DD HH:mm
- **Release Manager**: @[Name]
- **Related Milestone**: [Milestone Name / Link]
- **Rollback Triggers**: Define error-rate, core-flow, and observation thresholds ahead of time based on service risk. Data corruption or security issues require immediate mitigation rather than waiting for a fixed 30-minute timer; any rollback must follow a verified recovery plan and data compatibility check.

---

## 1. Pre-Release Preparation

- [ ] **Code merged & tagged**: All included To-Dos are in `Done`, PRs are merged to main, and the release tag is cut.
- [ ] **Database change review**:
  - [ ] Includes DDL/DML scripts? ([ ] No / [ ] Yes, path: _______)
  - [ ] Are SQL changes backward-compatible with the currently running code during rollout?
  - [ ] Has a pre-release production DB snapshot/backup completed?
- [ ] **Configuration & environment variables**:
  - [ ] New/updated env vars, config center keys, and secrets staged in production? (List: _______)
  - [ ] Third-party callback URLs and IP allowlists confirmed?
- [ ] **Artifacts verified**: CI/CD images or build artifacts verified in Staging.

## 2. Release Execution Order

1. [ ] **Step 1**: Run incremental DB migrations; confirm zero errors and no long table locks.
2. [ ] **Step 2**: Apply production config updates / warm up Redis cache if needed.
3. [ ] **Step 3**: Roll out backend services (canary one node first, check logs, then roll out remaining nodes).
4. [ ] **Step 4**: Deploy frontend static assets and refresh CDN cache.
5. [ ] **Step 5**: Enable scheduled jobs / message queue consumers.

## 3. Post-Release Verification

- [ ] **Core flow smoke test (QA lead)**: Auth, primary business flows, and payment/state transitions verified.
- [ ] **Monitoring & logs check (Release Manager)**: Watch error logs, CPU/memory, and slow queries for 15 minutes post-release.
- [ ] **Announcement**: Post "v1.4.0 release complete" in the team channel.

## 4. Rollback Plan

1. [ ] Revert backend/frontend service images to previous stable tag: `[Previous tag, e.g., v1.3.2]`
2. [ ] Config restoration notes: `[Configs to revert, or note if backward-compatible]`
3. [ ] Data recovery & compatibility strategy: `[Document forward-compatible fix, repair plan, or verified restore procedure; never run unverified reverse SQL in production]`

Fold Documentation Updates Back into the Delivery Flow

A To-Do card description works best when it holds the goal, scope boundaries, AC checklist, and a deep link to the Wiki—rather than a pasted 5,000-word design doc. Conversely, linking back to the implementation ticket from the Wiki makes it easy to see why a design evolved later.

What Belongs in a Ticket vs. What Belongs in the Wiki

Which Changes Warrant a Wiki Update Before Done

When a ticket changes environment configuration, database schemas, external API contracts, or deployment mechanics, folding the corresponding Wiki update into your DoD ensures the next engineer who touches the system isn’t left guessing. This doesn’t require inventing a bureaucratic sign-off gate—just a shared check during review and QA that necessary operational docs stayed in sync:

flowchart TD
    A["Dev completes coding & self-test"] --> B{"Touches any of the 4 architecture/ops areas?"}
    B -->|No: routine feature change| D["Enter Testing & CR verification"]
    B -->|Yes| C["Update corresponding Leantime Wiki page"]
    C --> D
    D --> E{"QA & Tech Lead DoD check"}
    E -->|Code verified & Wiki synced| F(["Move to Done"])
    E -->|Wiki missing or out of sync| G["Return to In Progress"]
    G --> C

1. Environment variables & config changes: Added or modified config keys, secrets, third-party endpoints, or feature flags \rightarrow sync to 01-Onboarding & Local Setup and 05-Runbooks & Release Checklists.
2. Database & cache schema changes: New tables, altered column semantics, new core indexes, or Redis key conventions \rightarrow sync to 04-API Contracts & Database Schema.
3. External or cross-client API changes: Field names, status enums, or pagination rules adjusted during integration \rightarrow update 04-API Contracts before merging so docs never lag behind verbal agreements.
4. New infrastructure or operational scripts: New middleware, cron jobs, data repair scripts, or special deployment ordering \rightarrow record in 03-Architecture (ADR) or 05-Release Checklists.

Leave Room for Unplanned Work

Everything above looks neat on paper, but real engineering weeks rarely go strictly according to plan. Production bugs, ops questions, and urgent business requests all compete for the same people’s time. If your board only tracks planned features, your capacity numbers and burndown charts will quickly drift away from reality.

A Capacity Buffer and Clear Trade-Offs Beat a 100% Packed Plan

I prefer reserving a realistic buffer during Sprint Planning and separating production incidents, urgent mid-sprint feature requests, and routine operational support into distinct tracks. All three can be legitimate work, but they shouldn’t all be shoved silently into the sprint while pretending the original plan still holds.

Treat the Buffer as a Hypothesis You Calibrate Over Time

During Sprint Planning, reserve 15% to 20% of net capacity (after deducting leave, meetings, and fixed duties) as a buffer, then adjust that percentage over time based on how much unplanned support actually shows up. Use the exact same deduction definition as the capacity formula earlier—deduct it once, and don’t double-discount when forecasting from historical velocity that already reflects past buffer usage.

• Watch out for single-point-of-failure bottlenecks: If only one engineer understands a legacy module and gets pulled into a half-day production issue, the impact isn’t just four hours of lost coding—it can stall integration and reviews for others too. Aggregate team slack doesn’t mean every specialty has spare capacity.
• Don’t burn the buffer just because it’s there: If Week 2 Wednesday arrives and the buffer is still untouched, help clear code reviews, testing, regression checks, or tech debt first. Only pull a tiny Ready item from the top of the Backlog if the PO and team agree it can finish end to end without risking the Sprint Goal or quality gates.

Triage Unplanned Work by Its Nature First

When unplanned work appears mid-sprint, decide whether it requires an immediate emergency response, a scope swap, or routine support batching:

flowchart TD
    A["Unplanned work appears mid-sprint"] --> B{"What kind of work is it?"}

    B -->|"1. Blocking Prod Incident (P0/P1)"| C["Start emergency mitigation immediately"]
    C --> D["Restore service first, then log Bug card in Leantime"]
    D --> E["Tag #Hotfix, link to current Sprint & log actual hours"]
    E --> F["Consumes 15%~20% Buffer; review in Sprint Retro"]

    B -->|"2. Urgent Mid-Sprint Business Request"| G["PO evaluates urgency & value"]
    G --> H{"Must it ship inside this Sprint?"}
    H -->|"No: can wait for next sprint"| I["Place in Product Backlog for normal prioritization"]
    H -->|"Yes: delay causes major business impact"| J["Apply Swap In / Swap Out trade-off"]
    J --> K["Tech Lead & devs size new card (X SP)"]
    K --> L["PO moves equivalent X SP of unstarted To Do cards back to Backlog"]
    L --> M["Tag new card #Swap-In and pull into current Sprint"]

    B -->|"3. Routine Ops / Data Query (< 2h)"| N["Log under on-call engineer's shared Support Bucket card"]

Scenario 1: P0/P1 Production Incidents — Restore Service First, Log Afterward

1. Stop the bleeding first: The Tech Lead pairs the relevant developers and DevOps to roll back or ship a hotfix immediately—nobody waits to fill out a Leantime ticket before fixing production.
2. Backfill the record within 2 hours of recovery: Once service is stable, create a Type = Bug, Priority = Critical card in the current sprint prefixed with [Hotfix], add the #Hotfix tag, and log the actual time spent.
3. Alert when the buffer overflows: If cumulative #Hotfix hours exceed the sprint’s 15% to 20% buffer, flag it at the next standup so the PO and team can negotiate which lower-priority sprint stories need to be deferred.

Scenario 2: Urgent Mid-Sprint Feature Requests — Discuss What Gets Deferred (Swap In / Swap Out)

When a stakeholder asks to squeeze an urgent request into an active sprint, use a Swap In / Swap Out conversation to decide what gives way. Matching story points is only a starting point—you still need to check dependencies, sunk work on in-flight cards, and whether QA can absorb the change.

When communicating externally, framing the trade-off works much better than flatly saying “we don’t have time”: explain that capacity is fully committed, and lay out which unstarted item would need to move to next sprint if the new request takes priority. The PO and delivery team still own that feasibility conversation together rather than dumping the raw mechanics on external stakeholders.

Batch Routine Support Without Flooding the Board

Running ad-hoc SQL exports for operations, answering tier-2 support questions, or checking environment hiccups might take 30 to 90 minutes each, but together they eat up real engineering time. Creating a standalone parent card for every 40-minute request floods the Kanban board; ignoring them completely leaves everyone wondering why feature work felt slow.

A practical middle ground is combining a shared support bucket card with a weekly on-call rotation (Batman). Keep in mind that genuine technical debt requiring independent verification or multi-day work still belongs in the Backlog as proper cards rather than hiding inside a support bucket forever.

Using Bucket Cards and Rotation to Make Support Cost Visible

1. Create fixed-budget bucket cards during Sprint Planning At the start of each sprint, create 1 or 2 recurring parent To-Do cards that draw from your reserved buffer:

2. The 2-hour rule of thumb and lightweight logging
   • Routine tasks under 2 hours: Add a subtask under the appropriate bucket card after handling the request, noting what was done, who handled it, and the time spent via Time Tracking entries (rather than overwriting a single total number). Production incidents, security issues, and defects needing regression tests still get standalone cards regardless of duration.
   • Items taking 2 hours or more: Create a proper Story or Task in the Backlog and size it normally.
3. Pair with a weekly on-call developer (“Batman”) rotation
   • Weekly rotation: Rotate weekly across the 5 developers, with the Tech Lead acting as escalation backup rather than double-counting in the 5-person pool. Update the bucket card assignee at the mid-sprint handoff while recording who actually handled each subtask.
   • Single intake point: Route routine ops and support queries to the week’s on-call engineer first so the other 4 developers can stay in deep coding flow.
   • Turn recurring pain into engineering work: If #Ops-Bucket hours repeatedly blow past 24 hours across consecutive sprints, use the subtask log during Sprint Planning to justify building self-service admin tools or automation.

Common Pitfalls I Watch Out For When Using the Tool

1. Splitting Subtasks into Hour-by-Hour Micromanagement

• Symptom: A 3-point story gets chopped into 15 tiny subtasks (“create table 1h”, “write entity 0.5h”, “write DAO 1h”, “write controller 1h”…), and engineers spend half an hour every day dragging tickets around.
• Adjustment to try:
  1. Keep subtasks at the half-day to full-day level (4 to 8 hours): 3 to 6 subtasks per normal story is plenty, with no mandatory minimum. Don’t pad simple work just to create subtasks.
  2. Use markdown checklists for tiny coding steps: Put 20-minute implementation reminders (“add index”, “update DTO”) inside the card description or comments as personal notes rather than separate subtasks.

2. Turning Story Points into Individual KPI Scorecards

• Symptom: Management ranks developers at the end of the month by individual story points completed. Within two sprints, estimates inflate (a 2-point story gets called a 5), and nobody wants to review code or tackle shared refactoring.
• Adjustment to try:
  1. Decouple story points from individual performance reviews: Use Effort strictly at the team level (Team Velocity) for capacity forecasting—never export individual point leaderboards.
  2. Keep anchor stories in the Wiki: Pin three past stories representing 1 point, 3 points, and 5 points in the Wiki as a shared baseline for relative sizing.

3. “Zombie Boards” Updated Only Five Minutes Before Standup

• Symptom: The board sits frozen from Monday to Thursday, then everyone scrambles to drag cards at 09:55 before standup—or dumps ten cards straight from To Do into Done on Friday afternoon.
• Adjustment to try:
  1. Tie board updates to natural engineering transitions: Spend 10 seconds updating the card at three concrete moments:
     • Checking out a feature branch (git checkout -b feat/LT-xxx) \rightarrow move to In Progress.
     • Opening a PR/MR and finishing self-test \rightarrow post the handoff note and move to Testing & CR.
     • Hitting an external wait or ambiguity lasting over 2 hours \rightarrow add [🔴Blocked] and @mention the counterpart.
  2. Update live during standup: If someone says “that’s already in testing” while the card still sits in In Progress, move it on screen together and check whether the handoff note is attached.

4. Cramming All Testing into Week 2 Thursday (Mini-Waterfall)

• Symptom: Developers code heads-down for the first eight days while QA has nothing to test; on Thursday afternoon of Week 2, ten stories land in Testing & CR at once and overwhelm QA.
• Adjustment to try:
  1. Watch the two mid-sprint flow checkpoints: Check whether roughly \ge 30\% of stories have entered Testing & CR by W1 Thursday/Friday, and review any unsubmitted feature stories at W2 Wednesday 18:00 (Feature Code Freeze).
  2. Keep individual WIP low: Limit each developer to 1 to 2 active stories in In Progress—help finish and verify current work before starting a third card.

5. Retrospectives That Produce Venting Instead of Follow-Through

• Symptom: The team spends an hour filling the retro board with sticky notes, nods in agreement, and then repeats the exact same pain points in the next sprint because nobody owned the follow-up.
• Adjustment to try:
  1. Pick only 1 to 2 actionable items: Vote on the top 1 or 2 pain points that the team can actually address within its own workflow or codebase.
  2. Turn them into candidate Tasks before leaving the room: Create [Retro Improvement] To-Do cards with a clear owner and completion criteria, queue them as candidates for next sprint’s planning, and check their impact at the next retro.

Start with a Two-Sprint Trial Instead of Rolling Out Every Rule on Day One

Writing down a comprehensive process is much easier than getting a team to sustain it. When introducing a setup like this, I prefer starting small: make current work visible, agree on what Done means, and only add more structure when a real pain point calls for it.

Sprint 1: See Whether Work Can Flow Smoothly Across the Board

A single project workspace, a handful of well-clarified stories, the To Do → In Progress → Testing & CR → Done flow, and a Wiki landing page with your basic card templates are enough to get started. Keep the Backlog as the unassigned sprint filter rather than adding extra board columns.

Instead of worrying about whether story-point estimates are accurate in Sprint 1, pay attention to basic flow signals: how often developers have to stop and ask for missing requirements after starting a card, where PRs and testing wait the longest, whether unplanned support is getting recorded, and whether card statuses reflect reality. Use the first Review and Retro to talk through those observations and pick one or two small adjustments.

Sprint 2: Check Which Agreements Actually Helped

When planning Sprint 2, refer back to Sprint 1’s completed stories, attendance, and unplanned interruptions—remembering that a single sprint is just one data point, not a stable velocity baseline. If testing piled up at the end of Sprint 1, look at whether stories were too big or handed over too late. If ad-hoc support kept interrupting feature work, introduce the weekly on-call rotation and bucket cards. If missing config or API notes caused friction during handoffs, tighten the Wiki check in your DoD.

After two sprints, the question isn’t whether the team hit an arbitrary “maturity score.” It’s whether you can explain the gap between plan and reality, and whether the records in Leantime helped the team make clearer trade-offs without feeling like busywork.

Closing Thoughts

Revisiting small-team Agile practices from a TPM perspective reminded me that the value of a workflow comes down to whether it cuts waiting time and makes trade-offs transparent—not how textbook-complete it looks. Leantime gives those working agreements a clean, self-hosted home, but no tool can set priorities or guarantee quality on its own.

What I’ve outlined here is a practical starting point shaped by hands-on trial runs. Make the work visible, get feedback early, and adjust based on real sprint records. Whenever a field, meeting, or rule stops helping the team ship and learn, drop it in the next retrospective.

Version Notes & References

• Leantime v3.9.8 Source Tree: Baseline version used to verify tool capabilities in this post.
• Ticket Types, Effort, Priority & Status Categories: Distinguishes built-in system options from the subset our team agreements use.
• Milestone Progress Calculation: See getMilestoneProgress, which weights ticket Effort by Priority factor.
• Sprint Statistics Implementation: Used to verify task counts, Effort, hours, and daily snapshot behavior.
• Retrospective Canvas Template & Wiki Repository: Verified built-in retro columns and hierarchical Wiki article support.
• Scrum Guide 2020: Reference baseline for distinguishing official Scrum accountabilities and artifacts from team-level working agreements.