Agile tools: Jira and Confluence

In short

Jira is an issue- and work-tracking system used to plan, assign, track and report software work as *issues* (epics, stories, tasks, bugs, sub-tasks) moving through a configurable workflow on a Scrum or Kanban board. Confluence is the companion wiki where the team writes the durable knowledge — requirements, design documents, meeting notes, runbooks, retrospective records — with pages linked both ways to Jira issues. Together they are the default delivery toolchain in almost every Indian IT services firm and product company (TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Accenture India, Flipkart, Razorpay, Freshworks, Zoho's own teams), so "have you worked on Jira?" is a near-certain screening question in placement and lateral interviews. University syllabi examine them under Software Engineering / Agile Software Development practical labs and viva (AICTE model curriculum, CBCS software engineering lab), typically as: create a project, define a sprint, write stories with acceptance criteria, track a burndown, document in a wiki. The examinable skill is not clicking buttons but reading the artefacts — backlog, board, burndown, velocity, cumulative flow — and drawing the right conclusion.

Explained

Jira's data model: issues, hierarchy, fields and workflows

• Issue (now also called a "work item" in Atlassian's current wording): the atomic unit of work. Every issue has a key like ABL-142 (project key + running number), a type, a status, a reporter, an optional assignee, and any number of fields.
• Standard hierarchy (bottom-up): Sub-task → Story / Task / Bug → Epic → (Initiative/Theme, available only with Advanced Roadmaps, now called Plans, in the Premium and Enterprise tiers). An epic is a large body of work spanning sprints; a story is a user-visible slice finishable in one sprint; a sub-task is one person's share of a story.
• Issue types are grouped into an *issue type scheme* per project. Common set: Story, Task, Bug, Sub-task, Epic, Spike (time-boxed investigation), Improvement.
• Fields: system fields (summary, description, priority, labels, components, fix version, due date) and custom fields (Story Points, Sprint, Acceptance Criteria, Severity, Environment). Story Points is a custom field whose internal id (customfield_100xx) differs per site — never hardcode it without checking.
• Workflow = statuses + transitions. A minimal flow: To Do → In Progress → In Review → In QA → Done. Each transition can carry:
  • Conditions — who may perform it (e.g. only the assignee);
  • Validators — what must be true (e.g. a fix version must be set);
  • Post-functions — what happens automatically (set resolution, assign to reporter, fire a webhook).
• Status vs resolution: status is *where* the issue is; resolution is *why it stopped* (Done, Won't Do, Duplicate, Cannot Reproduce). An issue in Done with an empty resolution shows as unresolved and silently pollutes every report — a classic configuration bug.
• Grouping fields: *Components* (sub-parts of a product, e.g. Checkout, Payments), *Labels* (free text, uncontrolled), *Fix Version / Release* (what ships when), *Sprint*, *Epic Link / Parent*.
• Schemes make configuration reusable across projects: permission scheme, notification scheme, issue security scheme, screen scheme, field configuration scheme, workflow scheme.
• Project types: *team-managed* (configured by the project's own admin, fast, isolated) versus *company-managed* (shared schemes, governed centrally, needed for cross-project reporting and audits). Large Indian delivery organisations standardise on company-managed.

Boards, sprints and the Scrum / Kanban distinction

• A board is a *view* over a JQL filter, not a container. Two boards can show the same issues differently; deleting a board does not delete issues.
• Product backlog: the ordered list of everything wanted, refined ("grooming") so the top items are small, estimated and have acceptance criteria.
• Scrum board: work is pulled into a fixed-length sprint (commonly 2 weeks in Indian teams), the sprint is started, and the board shows only that sprint. On completion, incomplete issues go back to the backlog or to the next sprint.
• Kanban board: continuous flow, no sprints, WIP limits per column; a column over its limit turns red and the team must swarm to clear it before pulling new work.
• Swimlanes split the board horizontally (by assignee, epic, priority, or an expedite lane for production issues); quick filters narrow it; card colours encode priority or issue type.
• Definition of Ready / Definition of Done are usually encoded as a checklist on the card or a Confluence page linked from the board — Jira does not enforce them unless you add validators.
• Reports that are directly examinable:
  • Sprint burndown — remaining story points (or hours) against the ideal straight line; a flat start plus a cliff at the end signals work not broken down or status updated only at the review.
  • Velocity chart — committed versus completed points for recent sprints; used for forecasting, never for comparing two teams.
  • Sprint report — scope added or removed mid-sprint (scope creep) and what carried over.
  • Cumulative flow diagram (CFD) — stacked area of items per status over time; a widening band = a bottleneck, parallel bands = stable flow.
  • Control chart — cycle time per issue with a rolling average; shows variability, not just the mean.
  • Epic burndown / release burndown — progress toward a release across sprints.

JQL, filters, dashboards and automation

• JQL (Jira Query Language) is the query layer behind every board, filter, dashboard gadget and report: field operator value [ORDER BY field].

project = ABL AND sprint in openSprints() AND assignee = currentUser() ORDER BY priority DESC
project = ABL AND issuetype = Bug AND priority in (Highest, High) AND resolution = EMPTY
project = ABL AND status CHANGED TO "Done" DURING (startOfMonth(), endOfMonth())
project = ABL AND parent = ABL-100 AND statusCategory != Done
created >= -14d AND labels = payments AND component = "Checkout"
project = ABL AND assignee WAS "priya" AND status WAS "In QA" ORDER BY updated DESC

• Key operators: =, !=, >, <, in, not in, ~ (contains), IS EMPTY, WAS, CHANGED. Functions: openSprints(), closedSprints(), currentUser(), membersOf(), startOfWeek(), endOfMonth(), now(), -7d, -4w.
• Saved filter = a named JQL query; shareable, and the basis of boards and subscriptions (a filter can email its result on a schedule).
• Dashboards are made of gadgets fed by filters: Filter Results, Two-Dimensional Filter Statistics, Created vs Resolved, Pie Chart, Sprint Health, Burndown.
• Automation rules (no-code, built in) follow *trigger → condition → action*:

WHEN   issue transitioned to "Done"
IF     issuetype = Story AND all sub-tasks are Done
THEN   set Resolution = Done
       comment "Closed automatically on sub-task completion"
       send Slack/Teams message to #release-train

Typical rules: auto-assign bugs by component, move the parent when all children are done, escalate an issue untouched for 5 days, create release-note sub-tasks, sync status with a linked issue.

• Integrations: Git providers (a branch or commit named ABL-142 fix rounding attaches itself to the issue; the development panel then shows branches, commits, PRs and builds), CI/CD (Jenkins, Bamboo, GitHub Actions), chat (Slack, Teams), test management (Zephyr, Xray), and the REST API (/rest/api/3/issue) for custom scripts.
• Jira Service Management is a separate product for ITSM — queues, SLAs, request types, approvals, change management — frequently paired with Jira for the product team and used heavily in Indian managed-services accounts.

Confluence: structure, pages and the Jira link

• Hierarchy: Site → Space (one per team, product or project; has its own permissions and home page) → Pages → child pages, arranged in a tree.
• Page anatomy: rich text editor, version history with per-version diff and restore, inline and page comments, @mentions, labels (for cross-space search), watchers, page restrictions (view/edit), and *Blog posts* for dated announcements.
• Templates and blueprints enforce consistency: Meeting Notes, Decision (records a decision, its owner, status and context), Product Requirements, Retrospective, How-to Article, Troubleshooting Article. Teams also author their own templates — an HLD/LLD template, a test strategy template, a release checklist.
• Macros are the exam-worthy bit:
  • Jira Issues macro — embeds a live JQL result or a single issue into a page; the status badge updates itself.
  • Jira Chart macro — pie/created-vs-resolved/two-dimensional charts from a filter.
  • Page Properties + Page Properties Report — turns a set of child pages into a roll-up table (the standard way to build a decision log or a meeting-notes index).
  • Table of Contents, Include Page, Excerpt / Excerpt Include, Children Display, Expand, Info / Note / Warning / Tip panels, Status lozenge, Task list, Code block, Attachments, Recently Updated.
• Two-way linking: creating a Confluence page from an issue, or inserting an issue into a page, records a *link* visible on both sides; a Jira epic's "Confluence pages" panel is where the specification lives. A story's description should hold the slice and its acceptance criteria; the full specification belongs on a Confluence page linked to the epic.
• Newer capabilities (dates vary by tier and roll-out, so verify on the site you use): Whiteboards (free-form planning that converts stickies into Jira issues), Databases (structured tables with typed columns), Smart Links, and Rovo (which absorbed Atlassian Intelligence; included in paid Cloud plans) for summarising pages, drafting and natural-language search/JQL. Availability differs between Free, Standard, Premium and Enterprise plans.
• Search and governance: full-text search with filters by space, label, contributor and date; archiving stale pages; page owners and review dates to stop wiki rot.

Administration, licensing and Indian practice

• Deployment: Atlassian ended support for Server licences on 15 February 2024; current options are Cloud (SaaS, tiers Free / Standard / Premium / Enterprise) and Data Center (self-hosted, clustered, for organisations with residency, regulatory or network isolation needs). Many Indian BFSI, PSU and defence-adjacent programmes run Data Center on in-country infrastructure for exactly this reason — but Atlassian has announced Data Center end of life: no new-customer sales after 30 March 2026, existing customers can buy until 30 March 2028, and Jira, Jira Service Management and Confluence Data Center become read-only on 28 March 2029, so these programmes are planning Cloud migrations. Pricing and tier features change — check Atlassian's current price list rather than quoting a number.
• Access control layers: global permissions → project permissions (via project roles: Administrator, Member, Viewer) → issue security levels → Confluence space permissions → page restrictions. Group membership normally flows from the corporate directory through SSO/SAML and SCIM.
• Audit and compliance: Jira's issue history and Confluence's page version history form the evidence trail used in CMMI appraisals, ISO/IEC 27001 and ISO/IEC 12207 process audits, and client quality gates. Requirements traceability (requirement → story → test case → defect → release) is commonly built with issue links plus a Confluence traceability matrix.
• Indian data protection: personal data appearing in issues, attachments or wiki pages is covered by the Digital Personal Data Protection (DPDP) Act, 2023; production data (customer names, Aadhaar/PAN numbers, card data) must not be pasted into Jira tickets or Confluence pages. Banking and payment projects additionally face RBI storage-of-payment-data directions and PCI DSS scope rules. Masking before attaching a log is a standard team rule.
• Alternatives you should be able to name: Azure DevOps Boards, GitHub Projects, GitLab Issues, Asana, ClickUp, Monday.com, Linear, Trello; Indian products Zoho Sprints / Zoho Projects and Freshworks' Freshrelease; open-source Redmine, Taiga, OpenProject; wiki alternatives Notion, SharePoint, MediaWiki, Docusaurus.
• Common anti-patterns to criticise in a viva: using Jira as a timesheet and judging people by closed-ticket counts; one giant "Development" status; no definition of done; a backlog of 3,000 unrefined items; specifications pasted into issue descriptions where they cannot be versioned or reviewed.

Key points

• Jira - issue tracking and board/sprint execution; Confluence - the versioned wiki holding specs, decisions and records. One tracks work, the other explains it.
• Issue key - PROJECT-NUMBER, permanent; it is what Git branches, commits, PRs and build logs reference.
• Hierarchy - Sub-task → Story/Task/Bug → Epic → Initiative (Initiative needs Plans, formerly Advanced Roadmaps / Premium).
• Workflow - statuses plus transitions, guarded by conditions, validators and post-functions; resolution is separate from status.
• Board - a view over a saved JQL filter, not a store of issues; deleting it loses no data.
• Scrum board - time-boxed sprints and a committed scope; Kanban board - continuous flow with WIP limits.
• Story points - relative size (effort + complexity + uncertainty), usually Fibonacci 1, 2, 3, 5, 8, 13; not hours and not comparable across teams.
• Velocity - story points *completed* per sprint, averaged over the last 3–5 sprints; forecasting input only.
• Burndown - remaining work versus the ideal line; CFD - WIP and bottlenecks; control chart - cycle time spread.
• WIP limit - the Kanban lever that shortens cycle time, justified by Little's Law.
• JQL - the query language behind filters, boards, dashboards and automation; WAS and CHANGED query history.
• Automation rule - trigger → condition → action; removes manual status hygiene.
• Confluence space - permission and navigation boundary; templates and blueprints keep pages uniform.
• Jira Issues macro / Page Properties Report - the two macros that turn a wiki page into a live report.
• Version history - Confluence keeps every revision with diff and restore; Jira keeps a full field-change history — this is the audit evidence.
• Server end-of-support 15 Feb 2024 - only Cloud and Data Center remain; Data Center is chosen for data residency in Indian BFSI and government work, but itself reaches end of life on 28 March 2029 (no new-customer sales since 30 March 2026).
• DPDP Act, 2023 - no unmasked customer personal data in tickets, attachments or wiki pages.
• Traceability - requirement → story → test case → defect → fix version, built from issue links and a Confluence matrix, is what CMMI/ISO audits inspect.

Formulas and examples

Example 1 - Sprint capacity and commitment. A team of 6 works a 2-week sprint (10 working days, 8-hour day, focus factor 0.75 → 6 productive hours/day). Two members take 2 days' leave each.

• Gross capacity = 6 × 10 × 6 = 360 h. Leave = 4 person-days × 6 = 24 h → net 336 h.
• Last three sprints delivered 36, 42 and 48 points → V̄ = (36+42+48)/3 = 42 points.
• Capacity-adjusted: person-days available = 60 − 4 = 56; commitment = 42 × 56/60 = 39.2 ≈ 39 points.
• Hours cross-check: a typical sprint used 350 h for 42 points → 8.33 h/point; 336 ÷ 8.33 = 40.3 points.
• Both methods land near 40 → commit 40 points, keep the 41st–45th as stretch.

Example 2 - Reading a burndown mid-sprint. Sprint scope 40 points over 10 days.

• Ideal burn rate = 40/10 = 4 points/day; ideal remaining at end of day 6 = 40 − 24 = 16 points.
• Actual remaining = 20 points → the team is 4 points behind.
• Actual rate so far = (40 − 20)/6 = 3.33 points/day; at that rate the 4 remaining days clear 13.3 points, leaving ≈ 6.7 ≈ 7 points unfinished.
• Rate needed to finish = 20/4 = 5 points/day, i.e. 50 % above the demonstrated rate — so de-scope about 7 points now rather than carry over at the review.

Example 3 - Little's Law on a Kanban board. The board holds 12 items in progress and the team finishes 4 items per week.

• Cycle time = 12 ÷ 4 = 3 weeks per item.
• Impose a WIP limit of 6 with unchanged throughput: cycle time = 6 ÷ 4 = 1.5 weeks — halved, with no extra people. This is the standard justification for WIP limits.

Example 4 - Lead time, cycle time, flow efficiency from the issue history. ABL-142: created 1 Oct 09:00, moved to In Progress 5 Oct 09:00, moved to Done 9 Oct 17:00. Developers logged 14 h of actual work.

• Lead time = 1 Oct 09:00 → 9 Oct 17:00 = 8 days 8 h = 8.33 days (200 h).
• Cycle time = 5 Oct 09:00 → 9 Oct 17:00 = 4 days 8 h = 4.33 days (104 h).
• Queue (waiting) time before pick-up = 200 − 104 = 96 h.
• Flow efficiency = 14 ÷ 104 × 100 = 13.5 % — typical, and it shows the lever is waiting, not coding speed.

Example 5 - Release forecast and cost. 300 points remain; velocities 36, 42, 48 (V̄ = 42); 2-week sprints; team of 6 at an average loaded cost of ₹12,00,000 per person-year; 26 sprints per year.

• Expected = ⌈300/42⌉ = ⌈7.14⌉ = 8 sprints = 16 weeks.
• Optimistic = ⌈300/48⌉ = ⌈6.25⌉ = 7 sprints = 14 weeks; pessimistic = ⌈300/36⌉ = ⌈8.33⌉ = 9 sprints = 18 weeks.
• Cost per sprint = 6 × 12,00,000 ÷ 26 = ₹2,76,923; cost per point = 2,76,923 ÷ 42 = ₹6,593.
• Expected release cost = 2,76,923 × 8 ≈ ₹22.2 lakh; quote the range ₹19.4–24.9 lakh, not a single figure.

Example 6 - Sprint quality metrics. Committed 40 points, delivered 36; 21 defects found inside the sprint, 3 escaped to production.

• Say-do ratio = 36/40 = 90 %. Defect density = (21+3)/36 = 0.67 defects per point.
• Defect escape rate = 3/(21+3) = 12.5 % — the number a QA lead actually tracks sprint over sprint.

Where it is used

• IT services delivery (TCS, Infosys, Wipro, HCLTech, Tech Mahindra, Cognizant, Capgemini India, LTIMindtree): Jira projects per client account, sprint reports and velocity feeding client governance decks; Confluence spaces holding BRDs, HLD/LLD, runbooks and the CMMI/ISO process evidence.
• Indian product and fintech companies (Flipkart, Razorpay, Zerodha, Swiggy, Zoho, Freshworks, PhonePe, CRED): Jira for release trains and bug triage, Confluence for RFCs, design docs, incident post-mortems and on-call runbooks.
• Job roles that are hired on this skill: Scrum Master and Agile Coach (board and report hygiene), Business Analyst/Product Owner (backlog, acceptance criteria, Confluence specs), Project Manager/Delivery Manager (dashboards, forecasts, capacity), QA Engineer (bug workflow, Zephyr/Xray test cycles), Jira Administrator/Atlassian Consultant (schemes, workflows, automation, migrations — a well-paid niche in India), Support/ITSM engineer (Jira Service Management SLAs).
• Regulated programmes (BFSI, insurance, healthcare, government IT): Data Center deployments for residency; traceability matrices and audit trails for RBI/IRDAI inspections, ISO 27001 and DPDP Act compliance.
• Campus and academic use: software engineering labs and final-year projects — a free Atlassian Cloud plan (small user cap, limits change) is enough to run a real backlog, two sprints and a wiki, and a Jira board with a clean burndown is strong evidence in a placement portfolio.
• Non-software teams: marketing campaigns, HR onboarding, recruitment pipelines and facilities requests run on the same boards, since Jira Work Management was folded into Jira.

Interview questions

• Q: What is the difference between Jira and Confluence? A: Jira tracks units of work through a workflow with boards, sprints and reports; Confluence is the versioned wiki holding the knowledge — requirements, designs, decisions, notes — and the two cross-link so an epic points to its specification.
• Q: Explain the Jira issue hierarchy. A: Sub-task sits under Story, Task or Bug, which sit under an Epic; an Initiative level above the Epic exists only with Plans (formerly Advanced Roadmaps) on Premium and Enterprise plans.
• Q: What is the difference between status and resolution? A: Status is the current workflow position; resolution records why the issue stopped (Done, Duplicate, Won't Do). An issue in Done with no resolution still counts as unresolved in filters and reports.
• Q: Write a JQL query for unresolved high-priority bugs assigned to you in the open sprint. A: project = ABL AND issuetype = Bug AND priority in (Highest, High) AND resolution = EMPTY AND assignee = currentUser() AND sprint in openSprints().
• Q: How do you calculate velocity and what should it not be used for? A: Sum the story points of items actually completed in a sprint and average the last 3–5; use it to forecast your own team's release date, never to compare teams or appraise individuals, since points are relative to one team's baseline.
• Q: Your burndown is flat for eight days then drops vertically on the last day. What does that tell you? A: Stories are too large or statuses are only updated at the end, so there is no real in-sprint visibility — break stories down and update the board daily.
• Q: What does a widening band in a cumulative flow diagram mean? A: Items are entering that status faster than they leave — a bottleneck, usually in code review or QA; fix it with a WIP limit and swarming rather than more intake.
• Q: How do WIP limits reduce cycle time? A: By Little's Law, cycle time = WIP ÷ throughput; halving WIP at unchanged throughput halves the average time an item spends in the system.
• Q: Difference between a team-managed and a company-managed project? A: Team-managed is configured independently by the project admin and is quick to start; company-managed shares workflows, fields and permission schemes across projects, which is required for governance and cross-project reporting.
• Q: How is Jira linked to Git and CI? A: Naming a branch or commit with the issue key attaches the development activity to the issue, so branches, pull requests, builds and deployments appear on the issue and can drive automation such as transitioning to In Review.
• Q: Give two Confluence macros you have actually used and why. A: The Jira Issues macro to embed a live JQL result (release scope that updates itself) and Page Properties with Page Properties Report to roll child pages — decisions or meeting notes — into one index table.
• Q: A manager wants to rank developers by tickets closed in Jira. What is your response? A: Ticket counts ignore size, complexity and collaboration and reward splitting work and avoiding hard problems; track team-level flow metrics — cycle time, escaped defects, say-do ratio — instead.
• Q: What happens to unfinished stories when a sprint closes? A: Jira asks where to move them — the next sprint or the backlog; the right practice is to return them to the backlog for re-prioritisation and re-estimation, and record the carry-over in the sprint report.

Common mistakes

• Treating story points as hours, or "converting" one team's points to another's — points are relative within one team only.
• Counting partially finished stories in velocity; only items meeting the Definition of Done at sprint end count.
• Confusing lead time with cycle time (lead time starts at creation, cycle time at the first active status) and quoting the mean when the distribution is heavily skewed — use the median and the 85th percentile.
• Leaving resolution unset, or adding a "Closed" status without a resolution, so dashboards and "Created vs Resolved" charts quietly misreport.
• Creating sub-tasks for every workflow step (Code, Review, Test) instead of using statuses — it inflates counts and destroys cycle-time data.
• Thinking a board stores issues: deleting a board deletes only the view; conversely, a board's filter can silently hide issues that are genuinely open.
• Pasting production data — customer names, PAN/Aadhaar numbers, card or log dumps — into tickets or wiki pages, a DPDP Act and PCI DSS exposure; mask before attaching.
• Writing the whole specification in an issue description instead of a Confluence page, losing version history, review comments and reuse.
• Adding scope mid-sprint without recording it, so the burndown looks like poor delivery when it was uncontrolled intake — the sprint report's scope-change section exists for this.
• Quoting a single release date from average velocity; always give a range from the best and worst recent sprints.

Related topics

SDLC and Agile · Business analysis and requirements gathering · Software project management and estimation · Git and version control · Software testing basics · System design case studies