Unit 15: Agile Project Execution and Control using Jira

I. Agile Project Management Orientation

Agile project management is an iterative and incremental approach in which teams deliver usable product increments, obtain feedback, and adapt plans frequently. The Agile Manifesto (2001) emphasizes individuals and interactions, working software, customer collaboration, and responsiveness to change. Jira is a work-management platform commonly used to implement Agile practices through backlogs, boards, workflows, sprints, issue tracking, and reports.

• Iterative delivery: Work is completed in short cycles rather than through one final delivery; Scrum commonly uses fixed-length sprints of one to four weeks.
• Incremental value: Each completed increment adds usable functionality, such as a login page or payment service, to the product.
• Customer feedback: Sprint reviews, demonstrations, and acceptance criteria connect development work to stakeholder needs.
• Adaptive planning: Priorities may change after each iteration as requirements, risks, or market conditions change.
• Transparency: Jira boards, issue statuses, assignees, and reports make progress and impediments visible.
• Inspection and adaptation: Teams inspect outcomes through reviews and metrics, then improve through retrospectives.
• Empirical control: Decisions are based on observed evidence such as completed issues, cycle time, defects, and sprint velocity.
• Agile roles: Scrum typically identifies a Product Owner, Scrum Master, and Developers, while Kanban does not prescribe specific roles.
• Definition of Done: A shared completion standard may require coding, review, testing, documentation, and successful deployment before an issue is marked done.

II. Agile Foundations and Jira Project Setup — Selecting and Configuring the Work System

A. Introduction to Agile and Jira interface

The Jira interface organizes Agile work into projects, issues, views, workflows, and reports so that teams can plan and control delivery from one system.

• Project: A project is the main container for related work; it has a project name, key, members, permissions, issue types, and configuration.
• Issue: Jira represents a unit of work as an issue, such as an Epic, Story, Task, Subtask, or Bug. An issue key such as PAY-42 combines the project key PAY with a sequence number.
• Navigation: Common project views include:
  • Backlog: Holds prioritized future work and, for Scrum, planned sprints.
  • Board: Displays issues as cards in workflow columns.
  • Timeline: Presents epics and related work against dates.
  • Reports: Provides charts based on issue and sprint data.
• Issue details: Typical fields include summary, description, assignee, reporter, priority, status, labels, components, estimate, attachments, and comments.
• Workflow: A workflow defines statuses and permitted transitions. A simple flow is:

To Do → In Progress → Code Review → Done

• Board columns: Columns visually group workflow statuses; for example, both Code Review and Testing may be mapped to an “In Progress” board category.
• Search and filters: Jira Query Language can retrieve precise issue sets:

project = PAY AND status != Done ORDER BY priority DESC

Here, PAY is the project key, status != Done excludes completed issues, and priority DESC places higher-priority issues first.

• Configuration models: Team-managed projects simplify local configuration, whereas company-managed projects support more standardized schemes shared across teams.

B. Creating Scrum or Kanban projects

Creating the correct project type aligns Jira’s planning features with either timeboxed Scrum delivery or continuous Kanban flow.

1. Scrum project

   • Purpose: Scrum supports work organized into sprints with a sprint goal, selected backlog items, and a potentially releasable increment.
   • Creation: Select a Scrum template, choose team-managed or company-managed configuration, enter a project name and key, and add members.
   • Core views: The backlog contains future work and sprint containers; the active sprint board tracks current execution.
   • Best fit: Scrum suits teams able to plan toward a goal for a fixed period, such as a two-week sprint.
   • Control mechanism: Commitment is reviewed through sprint scope, burndown, velocity, sprint review, and retrospective.

2. Kanban project

   • Purpose: Kanban supports continuous flow by pulling work according to available capacity rather than sprint boundaries.
   • Creation: Select a Kanban template, define columns, configure filters, and establish work-in-progress limits where supported.
   • Core measure: Cycle time measures elapsed time from work beginning to completion.
   • Best fit: Kanban suits maintenance, support, and operational teams receiving work continuously.
   • Control mechanism: A WIP limit such as three items in “In Progress” exposes congestion when a fourth item cannot be pulled.

• Explicit contrast: Scrum controls work through timeboxes and sprint goals; Kanban controls flow through pull policies, WIP limits, and continuous delivery.

III. Work Definition and Planning — Converting Product Goals into Executable Scope

A. Creating epics, user stories, and tasks

Jira issue types decompose a broad product objective into understandable, estimable, and assignable units of work.

• Epic: An epic represents a large outcome spanning multiple stories or sprints, such as “Online Payment Processing.” Stories are associated with the epic through Jira’s parent relationship.
• User story: A story expresses user value in a compact form:

As a <user>, I want <capability>, so that <benefit>.

Example: “As a customer, I want to save a card so that future checkout is faster.”

• Acceptance criteria: Criteria define observable conditions for acceptance, such as “expired cards are rejected” and “only the final four digits are displayed.”
• Task: A task records necessary work not naturally expressed as user-facing value, such as “configure the test database.”
• Subtask: A subtask divides a story or task into smaller actions, such as implementation, test automation, and documentation; it remains attached to its parent issue.
• Bug: A bug records behaviour that differs from an agreed requirement, such as a discount being calculated twice.
• Estimation: Teams may use story points for relative effort or time estimates for expected duration. One story point is not a fixed number of hours.
• Traceability: Parent links, issue links, versions, labels, and components connect strategic scope to implementation and release records.
• Quality standard: A well-formed issue has a concise summary, business context, testable acceptance criteria, priority, dependencies, and sufficient detail for execution.

B. Backlog management and sprint planning

Backlog management maintains an ordered, refined collection of work, while sprint planning selects a realistic set of items that supports one sprint goal.

• Product backlog: The backlog contains desired features, defects, technical improvements, and research items ordered primarily by value, urgency, risk, and dependency.
• Refinement: The team clarifies scope, adds acceptance criteria, splits oversized stories, identifies dependencies, and estimates upcoming work.
• Prioritization: High-value or risk-reducing items are moved upward through drag-and-drop ordering or ranking; priority fields alone do not necessarily determine backlog order.
• Readiness: A story should normally be understandable, small enough for a sprint, testable, and free from unresolved critical dependencies before selection.
• Capacity: Available effort must consider holidays, support duties, and team membership rather than relying only on historical velocity.
• Sprint creation: In a Scrum backlog, create a sprint, enter its name, duration, dates, and goal, then move selected issues into it.
• Sprint goal: The goal explains the intended outcome, such as “Customers can complete checkout using a saved card,” rather than listing unrelated tickets.
• Worked selection: If recent completed velocities were 22, 24, and 20 story points, the planning reference is:

Average velocity = (22 + 24 + 20) / 3 = 22 story points

Velocity is evidence for forecasting, not a productivity quota or a guarantee.

IV. Execution and Control — Monitoring Progress, Defects, and Scope Change

A. Sprint execution and issue tracking

Sprint execution moves planned issues through the workflow while Jira records ownership, status, discussion, and completion evidence.

• Sprint start: Starting a sprint fixes its timebox and activates its board; unfinished work from another active sprint should be resolved according to team policy.
• Issue assignment: Each active issue should have a clear assignee or ownership rule, while the reporter identifies who raised it.
• Status updates: Cards move from To Do to active statuses and finally to a status mapped to Jira’s Done category.
• Daily coordination: The board supports discussion of completed work, current work, blockers, and next actions without replacing direct team communication.
• Progress evidence: Comments, commits, pull requests, test results, attachments, and linked deployment information can document issue activity.
• Impediments: A blocked issue should be visibly flagged and linked to the dependency causing the block, such as PAY-51 blocks PAY-63.
• Scope control: Adding or removing issues after sprint start changes the planned scope and should be discussed with the Product Owner and team.
• Completion rule: Resolution and status must match the workflow convention; merely assigning 100% progress does not establish that acceptance criteria or the Definition of Done were met.
• Sprint closure: Completed items remain in the sprint record, while incomplete items may return to the backlog or move to a future sprint.

B. Bug tracking and change management

Bug and change control ensure that defects and revised requirements are evaluated, prioritized, approved, implemented, and traceable.

• Bug record: A useful bug includes environment, preconditions, reproduction steps, expected result, actual result, evidence, severity, and affected version.
• Severity and priority: Severity describes technical or business impact; priority determines handling order. A minor visual defect may have low severity but high priority before a public launch.
• Defect lifecycle: A configurable flow may be:

Open → Triaged → In Progress → Ready for Test → Done

• Triage: The team checks reproducibility, impact, duplication, ownership, release risk, and whether the report is actually a change request.
• Linking: A bug can be linked to the originating story, failed test, affected component, and corrective release version.
• Change request: A requirement change should record its rationale, requested scope, acceptance criteria, requester, and impact on cost, schedule, risk, and dependencies.
• Approval: High-impact changes may require Product Owner, change authority, security, or customer approval before backlog inclusion.
• Agile control: Agile welcomes valuable change, but does not imply uncontrolled interruption; non-urgent changes usually return to the backlog for reprioritization.
• Audit trail: Jira history records field changes, comments, status transitions, and timestamps, supporting accountability and post-release investigation.

V. Dashboards and Reports — Evidence-Based Visibility and Forecasting

A. Dashboards and reports: burndown chart, velocity chart, sprint report

Jira dashboards and Agile reports transform issue history into indicators for monitoring a sprint, forecasting capacity, and reviewing delivery outcomes.

• Dashboard: A dashboard combines configurable gadgets such as assigned issues, filter results, created-versus-resolved charts, sprint health, and two-dimensional statistics.
• Filter basis: Dashboard accuracy depends on its saved filter, permissions, workflow mapping, estimates, and disciplined issue updates.
• Burndown chart: This chart plots remaining sprint work against time.
  • Axes: The horizontal axis represents sprint time; the vertical axis represents remaining work, often story points or issue count.
  • Interpretation: A downward line indicates completed work; a flat section suggests no completion; an upward movement commonly indicates added scope or increased estimates.
  • Limitation: Burndown shows remaining quantity, not code quality, value delivered, or whether work is evenly distributed.
• Velocity chart: This chart compares committed and completed estimates across several sprints.
  • Use: A stable completed range supports near-term forecasting for the same team.
  • Caution: Velocity is team-specific and should not compare individuals or different teams because estimation scales differ.
• Sprint report: The sprint report separates completed issues from incomplete issues and highlights scope added or removed after sprint start.
  • Use: It supports sprint review, rollover decisions, and discussion of planning accuracy.
  • Evidence: Issue keys, estimates, and status outcomes reveal exactly which work met the completion criteria.
• Interpretation principle: Reports should trigger investigation rather than automatic judgment; scope change, blocked dependencies, incorrect workflow mapping, or delayed status updates can distort every chart.