Unit 15: Agile Project Execution and Control using Jira - Subjective Questions

Agile project management is an iterative and incremental approach in which software is developed through short cycles, frequent feedback, and continuous adaptation.

Key principles include:

• Iterative delivery: The product is developed in small, usable increments.
• Customer collaboration: Stakeholders regularly review the product and provide feedback.
• Responding to change: Requirements can be refined as business needs evolve.
• Working software: Progress is primarily measured through completed, functional software.
• Team collaboration: Cross-functional, self-organizing teams jointly plan and execute work.
• Continuous improvement: Teams use reviews and retrospectives to improve their product and process.

In project execution, these principles reduce delivery risk, expose problems early, and help ensure that the final product remains aligned with stakeholder needs.

The main components of the Jira interface are:

• Projects: Provide access to the Scrum or Kanban projects in which work is organized.
• Board: Visually displays issues in workflow columns such as To Do, In Progress, and Done.
• Backlog: Stores, prioritizes, and refines issues that are not yet selected for active development.
• Active sprint: Shows issues currently being executed during a Scrum sprint.
• Issues: Represent units of work such as epics, stories, tasks, and bugs.
• Roadmap: Presents epics and major work items across a timeline.
• Reports: Provide charts and summaries for measuring progress and team performance.
• Dashboards: Display configurable gadgets containing project information and metrics.
• Filters and search: Help users locate and analyze issues using basic search or Jira Query Language.

Together, these components support planning, assignment, tracking, collaboration, reporting, and control.

Scrum and Kanban are Agile approaches supported by different Jira board configurations.

Scrum project:

• Work is planned and completed in fixed-length iterations called sprints.
• A product backlog is maintained and prioritized.
• The team sets a sprint goal and selects work during sprint planning.
• Progress is commonly measured using burndown, velocity, and sprint reports.
• It is suitable when a team can plan work in regular cycles and deliver increments at predictable intervals.

Kanban project:

• Work flows continuously rather than through fixed sprints.
• Work-in-progress limits may be applied to workflow columns.
• Performance is evaluated using flow-related measures such as cycle time and throughput.
• Priorities can be changed whenever capacity becomes available.
• It is suitable for maintenance, support, operations, and teams receiving unpredictable requests.

Therefore, Scrum should be selected for iteration-based product development, while Kanban is more appropriate for continuous and demand-driven work.

A Scrum project can be created and configured through the following steps:

1. Select Projects and choose Create project.
2. Select a Scrum software project template.
3. Choose the appropriate project management type, such as team-managed or company-managed, depending on organizational requirements.
4. Enter the project name, project key, and project lead, and then create the project.
5. Configure issue types such as epic, story, task, subtask, and bug.
6. Review the workflow and map statuses to board columns such as To Do, In Progress, and Done.
7. Create epics and add user stories, tasks, and bugs to the backlog.
8. Rank backlog items according to business priority.
9. Configure estimation using story points or time estimates.
10. Create the first sprint, add selected issues, define the sprint goal, and start the sprint.

Permissions, notifications, fields, versions, and components may also be configured according to project governance needs.

The procedure for creating a Kanban project is:

1. Select Projects, choose Create project, and select a Kanban software template.
2. Choose whether the project will be team-managed or company-managed.
3. Enter the project name, key, and lead.
4. Create the project and open its Kanban board.
5. Configure workflow columns such as Backlog, Selected for Development, In Progress, Review, and Done.
6. Map each Jira status to the correct board column.
7. Create and prioritize issues in the backlog.
8. Add swimlanes, quick filters, card colors, and other board settings where required.
9. Define work-in-progress limits for active columns.

A work-in-progress limit restricts the number of issues allowed in a workflow stage. It helps the team:

• Avoid starting too many items simultaneously.
• Identify bottlenecks in the workflow.
• Encourage completion before new work is started.
• Improve flow, throughput, and delivery predictability.

When a limit is exceeded, Jira visually highlights the affected column so that the team can take corrective action.

The common Jira issue types are:

• Epic: A large body of work representing a major feature, objective, or business capability. It is usually divided into several smaller issues.
• User story: A requirement stated from the user's perspective that delivers identifiable value.
• Task: A general unit of work that must be completed but may not represent a user-facing requirement.
• Subtask: A smaller piece of work created under a story, task, or bug to divide implementation responsibilities.
• Bug: A defect in which actual software behavior differs from expected behavior.

Their typical relationship is hierarchical. An epic groups related stories, tasks, and bugs. Stories and tasks describe manageable backlog items, while subtasks divide those items into smaller implementation activities. Bugs may be linked to an epic or other issues and can also contain subtasks. This structure provides traceability from high-level business objectives to detailed technical work.

A user story should describe a small, valuable requirement from the perspective of its intended user. A common format is:

As a type of user, I want a capability, so that I receive a benefit.

For example: As a registered customer, I want to reset my password so that I can regain access to my account.

In Jira, the issue should include:

• A concise and descriptive summary.
• A detailed user-story statement.
• The business context and relevant assumptions.
• Clear acceptance criteria.
• Priority and estimate.
• Epic link or parent relationship.
• Labels, components, attachments, and dependencies where necessary.

Acceptance criteria define the conditions that must be satisfied for the story to be accepted. They should be specific, testable, and unambiguous. They may be written as a checklist or in Given-When-Then form. A good story should also follow the INVEST qualities: independent, negotiable, valuable, estimable, small, and testable.

The product backlog is an ordered collection of all known work required for a product. It may contain features, user stories, tasks, technical improvements, research items, and bugs.

Backlog management in Jira includes:

• Creating issues: Recording new requirements, defects, and technical work.
• Prioritizing: Ranking issues according to business value, urgency, risk, and dependencies.
• Refining: Clarifying descriptions, acceptance criteria, and implementation scope.
• Estimating: Assigning story points or time estimates.
• Grouping: Connecting issues to epics, versions, components, and labels.
• Splitting: Dividing oversized stories into smaller, deliverable items.
• Removing or closing obsolete items: Keeping the backlog relevant and manageable.
• Managing dependencies: Linking blocked and blocking issues.
• Preparing sprint candidates: Moving sufficiently refined issues toward the top of the backlog.

Continuous backlog management ensures that high-value, well-understood work is available for future sprint planning.

Backlog refinement is the recurring activity of reviewing and preparing future backlog items. The product owner and development team collaborate to improve clarity and ensure that upcoming work can be planned confidently.

The refinement process includes:

1. Reviewing the highest-priority backlog items.
2. Clarifying requirements and resolving ambiguities.
3. Adding or improving acceptance criteria.
4. Splitting large epics or stories into smaller items.
5. Estimating effort using story points or another agreed method.
6. Identifying technical risks and dependencies.
7. Updating priority, labels, components, and links in Jira.
8. Removing duplicate or obsolete issues.

An issue is ready for sprint planning when it:

• Has a clear description and business value.
• Contains testable acceptance criteria.
• Is small enough to complete within one sprint.
• Has been estimated by the team.
• Has known dependencies and risks documented.
• Can be tested and demonstrated.
• Satisfies the team's Definition of Ready, if one is used.

Sprint planning determines the sprint goal and the backlog items that the team intends to complete.

The process in Jira is:

1. Open the project's Backlog view.
2. Select Create sprint to add a new sprint container.
3. Review the ordered product backlog and confirm that candidate issues are refined.
4. Consider team capacity, previous velocity, leave, technical risks, and dependencies.
5. Drag selected stories, tasks, and bugs into the sprint.
6. Check the total estimate and adjust the scope to a realistic level.
7. Break selected issues into subtasks where useful.
8. Assign issues only when the team's working agreement requires early assignment.
9. Select Start sprint.
10. Enter the sprint name, sprint goal, start date, end date, and duration.
11. Confirm the sprint to activate it.

The result should be a coherent sprint backlog that supports a meaningful sprint goal. Selection of work represents a forecast based on capacity, not a guarantee that ignores emerging technical information.

During sprint execution, Jira's active board provides a shared view of current work. Each issue appears as a card in the workflow column corresponding to its status.

Jira supports daily tracking through:

• Status transitions: Issues are moved through stages such as To Do, In Progress, Code Review, Testing, and Done.
• Assignments: Each issue can show the person currently responsible for it.
• Comments and mentions: Team members can discuss progress and notify collaborators.
• Work logs: Time spent can be recorded where time tracking is enabled.
• Attachments and links: Evidence, designs, test results, and related issues can be associated with work.
• Flags: Blocked or urgent issues can be highlighted.
• Filters and swimlanes: Work can be viewed by assignee, epic, priority, or other criteria.
• Sprint metrics: Burndown and sprint reports reveal progress and scope changes.

During the daily Scrum, the board helps the team inspect progress toward the sprint goal, identify blockers, coordinate work, and update issue states.

A workflow defines the lifecycle followed by a Jira issue.

• A status represents the issue's current state, such as To Do or In Progress.
• A transition is an allowed movement from one status to another, such as moving an issue from In Review to Testing.
• Workflow rules may use conditions, validators, and post-functions to control who can perform transitions, verify data, and execute automatic actions.

A suitable software development workflow is:

To Do → In Progress → Code Review → Testing → Done

Additional transitions may return an issue from Code Review or Testing to In Progress when rework is required. A Blocked status may be included if the organization needs to report blocking explicitly.

Workflow statuses must be correctly mapped to Jira board columns. A well-designed workflow makes progress visible, supports consistent procedures, and produces reliable reports. Excessive statuses should be avoided because they increase administrative effort without necessarily improving control.

A typical bug lifecycle is:

1. Reported: A user or tester creates the bug.
2. Triage: The team confirms validity, severity, priority, ownership, and target release.
3. Selected or assigned: The bug is assigned for investigation and correction.
4. In progress: A developer analyzes and fixes the defect.
5. Resolved: A candidate fix is completed.
6. Testing or verification: The fix is retested and relevant regression tests are performed.
7. Closed: The expected behavior is confirmed.
8. Reopened: The issue returns to development if verification fails or the defect recurs.

A high-quality Jira bug report should contain:

• A clear summary.
• Environment and affected version.
• Preconditions.
• Exact reproduction steps.
• Expected and actual results.
• Severity and priority.
• Screenshots, logs, or error messages.
• Reproducibility information.
• Affected component.
• Links to related stories, tests, incidents, or duplicate bugs.

Complete and reproducible reports reduce investigation time and improve defect traceability.

Severity describes the technical or operational impact of a defect, whereas priority describes the order and urgency with which it should be addressed.

Examples of severity are:

• Critical: Causes data loss, security exposure, or complete service failure.
• Major: Prevents an important function from operating correctly.
• Minor: Causes limited disruption and may have a workaround.
• Trivial: Produces a small cosmetic or usability problem.

Examples of priority are Highest, High, Medium, Low, and Lowest.

A severe defect may have low priority if it affects an obsolete feature used by very few people. Conversely, a minor visual error may receive high priority if it appears on a major public release page.

In Jira, severity may be represented through a custom field, while priority is commonly a standard field. During triage, the team considers both values along with business impact, frequency, affected users, workaround availability, security risk, and release deadlines to determine assignment, scheduling, and escalation.

Change management ensures that modifications to requirements, scope, or implementation are evaluated and recorded before they are accepted.

A Jira-based process can include:

1. Create a separate change-request issue or record the proposal as a new story or task.
2. Document the reason, requested outcome, affected features, urgency, and requester.
3. Link the request to related epics, stories, bugs, versions, and requirements.
4. Analyze business value, effort, risk, dependencies, schedule impact, and technical impact.
5. Submit the request for approval by the product owner or designated change authority.
6. Record the decision, comments, approver, and date in Jira.
7. If approved, prioritize and estimate the resulting issues.
8. Place the work in the backlog or negotiate it into an active sprint.
9. Track implementation, testing, release, and closure through the workflow.

Changes during an active sprint should be controlled carefully. If urgent work is added, its effect on the sprint goal and existing scope should be made visible. Jira's history, links, comments, notifications, and audit information preserve traceability.

A Jira dashboard is a configurable page that displays project information through gadgets. It can combine information from one or more projects and saved filters.

To configure a monitoring dashboard, a project manager should:

1. Create a dashboard and define its name, description, sharing permissions, and layout.
2. Create saved filters for relevant projects, sprints, teams, issue types, priorities, or statuses.
3. Add useful gadgets such as Filter Results, Assigned to Me, Pie Chart, Created versus Resolved Chart, Two-Dimensional Filter Statistics, and Sprint Health.
4. Configure each gadget to use the correct project or saved filter.
5. Arrange gadgets so that critical indicators appear first.
6. Verify that all intended viewers have permission to access the underlying issues and filters.
7. Review the dashboard periodically and remove metrics that no longer support decisions.

An effective dashboard may show sprint progress, unresolved critical bugs, blocked issues, workload by assignee, issue distribution by status, and release readiness. It should support action rather than merely display large quantities of data.

A burndown chart displays the amount of sprint work remaining over time.

• The horizontal axis represents sprint time.
• The vertical axis represents remaining work, usually measured in story points or time.
• A guideline indicates the approximate rate needed to reach zero by the sprint end.
• The actual line reflects work completed and scope changes.

Interpretation includes:

• Steady downward movement: Work is being completed throughout the sprint.
• Flat line: No issues are reaching the completed status, possibly because work is blocked or too many items are in progress.
• Upward movement: Work or estimates have been added to the sprint.
• Sudden large drop: Several issues were closed together, which may indicate delayed board updates or oversized stories.
• Remaining work at sprint end: The team did not complete all forecast work.
• Early fall to zero: The sprint may have been under-planned or issue statuses may be inaccurate.

The chart should be used as a discussion aid rather than as an individual performance measure. Its accuracy depends on current estimates, correct status transitions, and proper mapping of completed statuses.

Velocity is the amount of estimated work completed by a team during a sprint, commonly measured in story points. The Jira velocity chart typically compares:

• Committed work: The total estimate selected when the sprint began.
• Completed work: The total estimate of issues that satisfied the completion criteria by the sprint end.

For forecasting, the team examines completed velocity over several recent sprints and uses a stable range or average as one input to future sprint planning. For example, if completed velocities are , , and story points, the simple average is:

The team might therefore initially consider approximately points, adjusting for leave, sprint length, risks, and unusual work.

Limitations include:

• Story points are team-specific and cannot fairly compare different teams.
• Velocity measures quantity of completed estimates, not customer value or quality.
• Changes in team membership or estimation practice reduce historical relevance.
• A short history produces unreliable forecasts.
• Treating velocity as a target can encourage estimate inflation.

Velocity is therefore a planning aid, not a productivity score.

The sprint report summarizes what occurred during a completed or active sprint. It commonly includes:

• The sprint goal and sprint dates.
• Issues completed during the sprint.
• Issues not completed and returned to the backlog or moved forward.
• Work added after the sprint started.
• Estimate or scope changes made during the sprint.
• Issue details such as type, key, summary, status, and estimate.
• A graphical view of progress over the sprint.

During the sprint review, the report helps stakeholders compare the forecast with the completed product increment and identify work that remains unfinished.

During the retrospective, the team can investigate patterns such as:

• Frequent scope additions.
• Repeated carryover of issues.
• Stories that were too large.
• Dependencies or blockers discovered late.
• Inaccurate estimates.
• Work completed but not reflected promptly in Jira.

The report should be interpreted with context. It supports evidence-based discussion but does not explain the root cause of every result by itself.

The three Jira reports answer different project-control questions.

Burndown chart:

• Focuses on a single sprint over time.
• Shows remaining estimated work.
• Helps identify slow progress, stalled work, and scope change during execution.

Velocity chart:

• Compares committed and completed estimates across several sprints.
• Shows the team's historical delivery pattern.
• Supports capacity-based forecasting for future sprint planning.

Sprint report:

• Provides issue-level details for a selected sprint.
• Separates completed, incomplete, and added work.
• Supports investigation of scope changes and carryover.

Used together, they provide complementary control:

1. The project manager uses the burndown chart for day-to-day inspection of the current sprint.
2. The sprint report is used to identify which specific issues caused incomplete work or scope variation.
3. The velocity chart is used to compare longer-term delivery patterns and improve future forecasts.
4. Findings are discussed during reviews, retrospectives, refinement, and sprint planning.

These reports should be combined with product quality, business value, defect trends, risks, and stakeholder feedback. No single chart provides a complete assessment of project health.