Task and Ticket — What They Are, Tracking Systems, and Working with Tasks

What Is a Task and a Ticket?

Task — a unit of work recorded in a tracking system. It contains a description, priority (Critical, High, Medium, Low), assignee, deadline, and status. In mobile development, a task could be “Add a profile screen with avatar,” “Implement feed pagination,” or “Update targetSdk to 35.” Each task is tied to a project, sprint, and a specific developer or team.

Ticket — a broader entity. A ticket can be a bug report (“App crashes on screen rotation on Android 14”), a feature request (“Add dark theme support”), a tech support inquiry (“Push notification not arriving”), or a manager’s assignment (“Prepare a crash rate report for the month”). The line between a task and a ticket is blurred: in Jira, both are combined into Issue. The key difference: a task always has an assignee, while a ticket may be a request without a specific assignee until triage.

In Scrum and Kanban, tasks are the main element of the backlog. Each task should meet the INVEST criteria (Independent, Negotiable, Valuable, Estimable, Small, Testable). Independent tasks can be implemented in any order. Estimable ones — the team can estimate effort. Small ones — fit within one sprint. Testable ones — have clear acceptance criteria. Large tasks (epics) are broken down into smaller ones until all criteria are met.

Task Types in Mobile Development

Feature — new application functionality. Example: “Biometric login screen (Face ID / Touch ID).” Feature tasks are always linked to a user story and have Acceptance Criteria. Estimation is in story points (1, 2, 3, 5, 8, 13). Bug — a defect found during development or testing. Bug ticket priority is determined by severity (crash → Critical, UI bug → Medium, typo → Low). In mobile development, a crash rate above 0.1% is a critical bug requiring immediate fix.

Tech Debt / Chore — technical tasks with no visible user impact: library updates (Dependency Bump), refactoring (Migration from ViewPager to ViewPager2), CI/CD setup, writing tests. Tech Debt tasks are often underestimated, although according to Stripe 2025, up to 30% of a mobile team’s time goes to maintenance and paying down tech debt. Ignoring Tech Debt leads to increased bugs and slower development of new features.

Additional types: Spike (research task — explore a new technology, write a POC), Task (any non-code work — documentation, design review), Improvement (enhancing existing functionality — optimizing screen load time). In Jira, issue types are customizable per project. The standard set for a mobile team: Story, Bug, Task, Improvement, Epic. Epic — a large theme uniting several stories. Example: “E-commerce: cart and checkout.”

Task Lifecycle: From Creation to Closure

Open (To Do) — task created but not started. Contains description, Acceptance Criteria, priority. In this status, the task must go through grooming (refinement and estimation) before entering a sprint. In Progress — developer started working. In mobile development, it’s important to link commits and pull requests to the task: in Jira via Smart Commits (APP-123 #comment fix bug), in GitHub/GitLab via keywords in the PR description (Closes APP-123).

In Review — code sent for review. Automatic checks: CI (Gradle build, lint, unit tests), SonarQube (code quality), Danger (changelog, tests). A developer cannot pick up the next task while the current one is in Review — this prevents multitasking. QA / Testing — tester verifies on real devices (Android — various OS versions and screen sizes, iOS — different iPhone models). If bugs are found, the task returns to In Progress with a comment.

Done (Closed) — task completed: code merged into main/master, tested, ready for release. Some teams add a Deployed status — the task reaches the user only after the build is released in app stores. It’s important to close tasks with a result comment: which version, which PR, what metrics changed. According to Linear (2025), teams that close tasks with a result description are 40% less likely to return to the same tasks.

The lifecycle may include a Blocked status — the task cannot be completed due to an external dependency (waiting for design, backend response, manager approval). Blocked tasks must have a comment with the reason and the date of the next check. A weekly review of Blocked tasks helps identify systemic delays in the development process. Blockers lasting more than 2 weeks require escalation to the product manager level.

Task Tracking Systems

Jira — the industry standard for teams of 10 or more. Supports Scrum and Kanban boards, advanced workflow customization, custom fields, automations, and Bitbucket/GitHub integration. Disadvantages: overkill for small teams, slow UI, complex configuration. For mobile projects, Jira is customized with: the Mobile-specific fields plugin (Platform, OS version, Device model), TestFlight and Firebase Test Lab integration, and release build automation. Jira is the choice for enterprise projects with bureaucratic processes.

Linear — a modern tracker for product teams. Fast UI, first-class keyboard shortcut support, built-in Cycle (sprint analog), GitHub and Slack integration. Advantages: quick task creation via CMD+K, automatic phase distribution (Triaged → Backlog → Upcoming → Current → Completed), built-in documentation and roadmaps. Linear is chosen by startups and product teams that value speed. In 2025, 40% of new mobile projects use Linear.

Trello — a simple kanban board for small teams (2–5 people). Cards with checklists, labels, due dates. Disadvantage: no sprints, limited analytics, hard to scale. YouGile — a Russian analog of Trello with kanban boards, chat, and video calls. Asana — a tracker focused on projects and timelines. Tracker choice depends on team size, budget, and preferences: Jira for enterprise, Linear for product teams, Trello/YouGile for startups. Important: the tool should be unified for the entire team — designers, developers, QA, managers all work in one system.

Best Practices for Task Management

Write Acceptance Criteria — acceptance criteria should be specific and verifiable. Bad: “Login screen works.” Good: “User enters email and password, clicks Log In. If credentials are correct — navigate to the main screen. If incorrect — show error “Invalid email or password.”” Acceptance Criteria (AC) is the contract between developer, tester, and product manager. Without AC, a task does not meet the Definition of Ready (DoR) and should not enter a sprint.

Link Everything. Commits, PRs, test cases, design mockups (Figma), Slack discussions — all should be linked to the task. In Jira, this is done via links in comments; in Linear, via automatic PR linking. The one-click rule: from task to design/code/tests — no more than one click. A developer opens the task and immediately sees the Figma mockup, PR link, and test cases. This speeds up onboarding of new team members by 30% according to Linear (2025).

Don’t Create Ghost Tasks. A task without a description, without AC, and without priority is garbage. If at the daily standup no one remembers why a task was created, it should be deleted or clarified. The 48-hour rule: if a task has been in In Progress status without activity for 48 hours, the developer must leave a comment about the reasons for the delay. According to Jira (2025), 60% of tasks idle for more than 3 days end up being closed without completion.

Task Decomposition: Epics, User Stories, and Sub-tasks

Epic — a large functional area uniting many stories. Example: “User Onboarding” includes “Welcome Screen,” “Interest Selection,” “Avatar Upload,” “Notification Settings.” User Story — a task from the user’s perspective. Format: “As a [role], I want [action] so that [value].” Example: “As a user, I want to log in with biometrics so I don’t have to enter my password every time.” User Stories are written by the product manager or product owner.

Sub-task — decomposition of technical work within a Story / Task. Example for Story “Profile Screen”: Sub-task 1: Build UI (XML / SwiftUI), Sub-task 2: Connect to ViewModel, Sub-task 3: Write Unit Tests, Sub-task 4: Snapshot Tests, Sub-task 5: UI Tests (Espresso / XCUITest). Decomposition rule: each sub-task is completed in 1–2 days. If a developer estimates a sub-task longer — break it down further. Sub-tasks are an internal team technique, they are not visible in the product backlog. The sum of sub-task estimates does not necessarily equal the estimate of the parent Story (part of the work is communication, code review, testing).

Decomposition pyramid: Epic (Quarter / Half-year) → Feature / Story (Sprint) → Task (1–3 days) → Sub-task (Several hours). The INVEST technique helps verify the quality of decomposition. If a task is not Independent (depends on others) — this signals incorrect decomposition. If a task is not Small (more than 8 story points) — it needs further breakdown. Common pattern: Epic → 5–15 Stories → each Story → 3–8 Sub-tasks. The final epic estimate = sum of Story estimates, but the first sprint usually gives a 20–30% margin of error in estimates.

Common Mistakes When Working with Tasks

Mistake 1: tasks are too large. A 2-week task is an epic that needs decomposition. Large tasks cannot be integrated into daily tracking; they sit in In Progress for weeks. Rule: maximum task size — 2–3 days of work. Anything larger must be decomposed. Side effect: the developer feels progress by closing 2–3 tasks per week instead of one giant one. This boosts motivation and schedule predictability.

Mistake 2: missing Acceptance Criteria. The developer implemented the feature, the tester verified — all good. Manager: “Where is the edit button?” — “It wasn’t in the task.” Without AC, each side understands the task differently. Result: rework, conflicts, missed deadlines. AC is a contract: if the task has no criteria, it’s not ready for the sprint. At grooming, the first thing checked is the presence of AC. If AC is missing, the task is sent back to the Product Manager for refinement.

Mistake 3: forgetting Tech Debt. The team only does Feature tasks sprint after sprint. Six months later: the build takes 15 minutes, Gradle is 3 major versions behind, tests fail on CI due to deprecation. Solution: reserve 20% of the team’s time for Tech Debt (Google SRE practice “SLO-based error budget”). Create at least one Tech Debt task for every Feature sprint. Ratio: for every 3 Feature tasks — 1 Tech Debt or Bug. This prevents tech debt accumulation and maintains development velocity.