By Nesha Zoric in workflow — 25 Nov 2025

LiteTracker Story Workflow: A Step by Step Guide

LiteTracker makes managing work visible and predictable. This guide walks through a practical story workflow so teams can plan, start, review, and finish work with confidence. Follow these steps to move stories from the icebox into done while keeping priorities clear and handoffs clean.

Step 1: Move a high priority story from the icebox

Start by reviewing the icebox and the current iteration. When an urgent enhancement appears, drag it from the icebox into the current iteration. LiteTracker enforces priority: work already in progress is always above unstarted items. You can place the new story at the top of the unstarted section so it becomes the next thing the team picks up.

Move the high-priority story from the Icebox into the Current Iteration.

Step 2: Estimate before you start

LiteTracker requires an estimate before you can start a story. Assign story points during your planning conversation. Once estimated, the Start button appears. Estimation keeps capacity realistic and maintains velocity calculations.

Assign story points before starting — story details show the Points field and Start button.

Step 3: Click Start to mark in progress

Click Start to change the story state to in progress. LiteTracker highlights in-progress work so the team can see at a glance who is doing what. If this story becomes the team’s top priority, drag it to the top of the in-progress list so it is visibly prioritized.

Click the Start button to mark a story in progress — Start buttons are visible on several stories here.

Step 4: Track development reviews and comments

During development, use reviews to track code review, unit test verification, or design sign-off. Each review has a type and a status. When a developer completes a review, they can mark it as pass or request revisions and add comments. Use the activity feed to document decisions, branch names, pull requests, and commits so the story history is a single source of truth.

Add a short review comment and mark the review as Pass.

Step 5: Finish development and Deliver for QA

Once development and associated reviews are complete, click Finish. That moves the story into a delivered state ready for QA or staging. Delivering signals that the build is available for formal acceptance testing or stakeholder review.

Click Finish then Deliver to move the story into Delivered for QA.

Step 6: QA review and accept or reject

When QA or a product manager reviews the delivered work, they can accept or reject the story. Use concise, actionable comments when rejecting so developers know exactly what to change. LiteTracker records these comments in the activity feed which maintains an audit trail of feedback and fixes.

QA adds a short comment and clicks Pass to accept the story.

Step 7: Handle rejects with Restart

If the PM or QA rejects a story, click Restart to move it back into in progress. The story then repeats the same cycle: develop, finish, deliver, and review. This preserve flow and keeps the accountability chain intact. LiteTracker also warns if you try to accept a story while tasks, reviews, or blockers remain incomplete, preventing accidental sign-offs.

Click Restart to move a rejected story back into In Progress.

Step 8: Iteration boundaries and velocity recalculation

Completed stories remain visible in the iteration until the iteration ends. When an iteration closes, LiteTracker moves completed work into the done panel and marks it with the iteration number. Any incomplete work rolls forward into the next iteration. At that point LiteTracker recalculates team velocity and replans the backlog based on actual delivery performance.

Done panel showing past iteration rows and point totals — completed work is tracked by iteration.

Step 9: Bug workflow mirrors feature workflow

Bugs follow the same lifecycle as features in LiteTracker. Start a bug, finish development, deliver for QA, and accept or reject. Because bugs are customer-facing fixes, they require the same review and acceptance rigor that features do.

Bugs follow the same lifecycle as features — the Bug Template is shown in the Icebox.

Step 10: Chores use a simplified workflow

Chores are internal or technical tasks that do not require customer acceptance. Examples include environment upgrades, research spikes, or sandbox setup. In LiteTracker, chores typically only need a Start and Finish. They jump to the top when started but do not require a deliver or accept step since there is no external sign-off.

Chore-style workflow example: stories with Start and Finish buttons visible in the Current Iteration.

Step 11: Use SCM integrations and the activity feed

Link branches, pull requests, and commits to stories so context travels with the work. LiteTracker surface SCM activity inside the story, and the activity feed should hold short notes about progress, troubleshooting, and decisions. Treat the feed as the story’s living log.

See GitHub commits and linked SCM activity in the story’s activity feed.

Step 12: Prioritization rules to keep flow steady

Remember these practical rules:

In-progress > unstarted. Work already started always outranks unstarted work.
Estimate first. Don’t start a story until it has story points.
Document activity. Add notes, links to PRs, and CI output to each story’s feed.
Use reviews. Capture code review and QA review results on each story.

Best practices for teams using LiteTracker

Adopt a consistent workflow so the entire team understands the lifecycle of a story. Use short, clear acceptance criteria so QA and PMs can validate work quickly. Keep comments actionable. If a story is rejected, include reproductions, screenshots, or links to failing tests.

Maintain a rhythm of estimation and planning so LiteTracker can calculate velocity accurately. Re-plan after each iteration to match what the team actually delivered. This keeps the backlog realistic and helps stakeholders set expectations.

How do I prioritize urgent work without disrupting in-progress tasks?

Place the urgent item at the top of the unstarted list. LiteTracker ensures in-progress work remains above unstarted items. If the urgent item must interrupt active work, communicate and reassign as necessary, but avoid placing unstarted work above in-progress work.

What happens if a story is accepted but has incomplete tasks?

LiteTracker warns you before accepting. Resolve incomplete tasks or reviews first, or add a clear blocker that explains why accepting is appropriate despite the incomplete items.

When should chores be used instead of features?

Use chores for internal tasks that do not directly deliver customer value or require sign-off. Examples include environment upgrades, research spikes, and maintenance work.

How does LiteTracker use story points and velocity?

Assign story points during planning. LiteTracker uses completed points over iterations to calculate velocity. At iteration boundaries LiteTracker recalculates velocity and replans the backlog to reflect the team’s delivery rate.

Can I see code commits and pull requests inside a story?

Yes. Integrate your source control so branches, PRs, and commits are visible on the story. This keeps development context and history attached to the work item.

Closing notes

Following a disciplined story workflow reduces handoff friction and keeps work flowing predictably. LiteTracker’s simple rules around estimated starts, in-progress visibility, and clear deliver/accept transitions help teams deliver value consistently. Keep the activity feed current, use reviews to capture verification, and treat iteration boundaries as moments to learn and replan.

Credits: This tutorial is created based on this original video Tracker Story Workflow