> Continuous Process Improvement > Software Development Lifecycle > Jira Software > Data Template

Your Software Development Lifecycle Data Template

Jira Software

Software Development Lifecycle Attributes (22) Software Development Lifecycle Activities (14) Extraction Guides (4)

Your Software Development Lifecycle Data Template

This template provides a clear roadmap for collecting the essential data required to analyze your Software Development Lifecycle. It outlines the core data fields to gather, the critical process steps to track, and practical guidance on extracting this information from Jira Software. Use this guide to prepare your event log for effective process mining.

Recommended attributes to collect
Key activities to track
Extraction guidance for Jira Software

New to event logs? Learn how to create a process mining event log.

Download Template

Software Development Lifecycle Attributes

These are the recommended data fields to include in your event log for comprehensive Software Development Lifecycle analysis.

5 Required 6 Recommended 11 Optional

	Name	Description
	Activity Activity	The name of a specific event or status change that occurred in the development lifecycle of an item.
Description This attribute represents a distinct step or milestone in the software development process. These activities are derived from changes in the Jira issue's status field or other significant events like code commits or reviews. In process mining, the sequence of these activities forms the process map. Analyzing activities helps identify the process flow, measure the duration of specific stages, and detect deviations from the standard workflow, such as rework loops or skipped quality gates. Why it matters Activities define the steps of the process, and their sequence is essential for visualizing the process flow, identifying bottlenecks, and analyzing process variations. Where to get Typically derived from the 'status' field transitions in the Jira issue history or changelog. It can also be enriched with data from connected development tools. Examples Development StartedCode Review PerformedQA Testing CompletedDeployed To Production
	Development Item DevelopmentItem	The unique identifier for a single unit of work, such as a story, bug, or task, within Jira Software.
Description The Development Item serves as the primary case identifier, representing a distinct unit of work like a feature, bug fix, or task. It links all activities from initial conception and planning through development, testing, and deployment for that specific item. In Jira, this typically corresponds to the issue key, for example, 'PROJ-123'. Analyzing this attribute allows tracing the full end-to-end lifecycle of each work item. It is the foundation for constructing process maps, calculating cycle times, and identifying variations in how different items flow through the development process. Why it matters This is the essential key for linking all related development activities together, making it possible to trace the journey of a single work item from start to finish. Where to get This is the standard 'key' field for an issue in the Jira Software Issue API object. Examples PROJ-101CORE-5432API-789
	Event Time EventTime	The exact date and time when a specific development activity or event occurred.
Description Event Time is the timestamp that records when an activity took place. This is the temporal foundation for all process mining analysis, providing the chronological order of events for each case. This attribute is critical for calculating all time-based metrics, including cycle times, processing times, and waiting times between activities. It enables the analysis of process performance over time, helping to identify when and where delays occur in the development lifecycle. Why it matters This timestamp is fundamental for sequencing events correctly and calculating all duration-based metrics, which are key to understanding process efficiency and identifying delays. Where to get This corresponds to the 'created' timestamp for each entry in an issue's changelog or history. Examples 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:00:00Z
	Last Data Update LastDataUpdate	The timestamp indicating when the data for this process was last refreshed from the source system.
Description This attribute records the date and time of the most recent data extraction from Jira Software. It provides context on the freshness of the data being analyzed. Knowing the last update time is important for understanding the timeliness of the process insights. It helps analysts and business users confirm that they are looking at current data and informs them of the cutoff point for the events included in the analysis. Why it matters Indicates the freshness of the data, which is essential for ensuring that analyses and dashboards reflect the most current state of the process. Where to get This timestamp is generated and recorded at the end of the data extraction, transformation, and loading (ETL) process. Examples 2024-03-15T02:00:00Z2024-03-16T02:00:00Z
	Source System SourceSystem	The system from which the development lifecycle data was extracted.
Description This attribute identifies the origin of the data. For this process, it will consistently be 'Jira Software', but it is useful for distinguishing data if multiple source systems are combined in a larger analysis. In a broader IT landscape, specifying the source system ensures data lineage is clear and helps in managing data quality and integration efforts across different platforms. Why it matters Provides clear data provenance, which is crucial when integrating data from multiple systems or for data governance and auditing purposes. Where to get This is a static value that should be added during the data extraction and transformation process. Examples Jira Software
	Assignee Assignee	The user currently assigned to handle the development item.
Description The Assignee is the individual responsible for the work item at its current stage. In Jira, this is a standard field that changes as the item moves between different people and teams. Analyzing the assignee is key to understanding resource allocation, workload distribution, and handoff points. It helps answer questions about which developers or teams are involved in specific stages, who is a bottleneck, and how work is distributed across the organization. Why it matters Identifies the responsible user or resource for an activity, enabling workload analysis, resource management, and understanding handoffs between individuals. Where to get This is the 'assignee' field within the 'fields' object of the Jira Issue API response. Examples Alice SmithBob JohnsonUnassigned
	Item Priority ItemPriority	The priority level assigned to the development item, indicating its urgency.
Description Item Priority defines the relative importance or urgency of a work item. Jira provides a standard 'priority' field with configurable levels like Highest, High, Medium, and Low. Analyzing priority is crucial for checking conformance and identifying bottlenecks for critical items. For example, the 'Priority Item Conformance Check' dashboard relies on this attribute to verify if high-priority items are being expedited as expected or if they are getting stuck in the same queues as low-priority items. Why it matters Helps in analyzing whether high-priority items are processed faster than low-priority ones and if they follow a more streamlined path, ensuring SLAs are met. Where to get This is the 'priority' field within the 'fields' object of the Jira Issue API response. Examples HighestHighMediumLow
	Item Status ItemStatus	The current status of the development item within its workflow.
Description This attribute reflects the specific stage of the development item at a given point in time, such as 'In Progress', 'In Review', or 'Done'. The sequence of status changes over time is what generates the activities for process mining. While the 'Activity' attribute represents the change event, the 'ItemStatus' provides the state of the item. It is useful as a dimension for filtering and analysis, allowing you to see how many items are currently in a specific state or to analyze the characteristics of items that remain in a certain status for a long time. Why it matters Provides a snapshot of where an item is in its lifecycle, which is essential for status-based analysis and understanding the current state of work in progress. Where to get This is the 'status' field within the 'fields' object of the Jira Issue API response. Examples To DoIn ProgressIn ReviewDone
	Item Type ItemType	The classification of the development item, such as Bug, Story, Task, or Epic.
Description Item Type categorizes the nature of the work being performed. Jira uses a standard 'issuetype' field to distinguish between different kinds of work items, which often have unique workflows. This attribute is essential for comparative analysis. It allows you to filter the process for specific types of work, for example, to compare the lifecycle of a 'Bug' versus a 'Story'. This helps identify if certain types of work are more prone to delays, rework, or deviations from the standard process. Why it matters Allows for segmenting the process analysis to compare how different types of work, like bugs versus new features, are handled and where their processes differ. Where to get This is the 'issuetype' field within the 'fields' object of the Jira Issue API response. Examples StoryBugTaskEpic
	Project Name ProjectName	The name of the Jira project to which the development item belongs.
Description In Jira, all work items are organized into projects. The Project Name provides high-level context, often corresponding to a specific product, team, or initiative. This attribute is a powerful dimension for filtering and comparison. It allows for analyzing and benchmarking the SDLC process across different projects or products. This can reveal which projects are more efficient, which have more rework, and whether different teams follow different process variants. Why it matters Enables process analysis to be segmented by project, product, or team, allowing for performance comparisons and identification of best practices. Where to get This is the 'project' field within the 'fields' object of the Jira Issue API response. Examples Mobile App DevelopmentCore PlatformData Science
	Team Name TeamName	The development team responsible for the work item.
Description Represents the specific agile or feature team assigned to the development item. In Jira, this is often implemented as a custom field, or it can be derived from other information like the project or a specific component. This attribute is essential for team-level performance analysis. It allows dashboards to be filtered to show metrics like cycle time, rework rate, and throughput for individual teams. This is crucial for the 'Inter-Phase Handoff Efficiency' and 'Developer Workload & Item Progress' dashboards. Why it matters Allows for performance measurement and comparison between different development teams, helping to identify high-performing teams and share best practices. Where to get This is often a custom field in Jira. Consult your Jira administrator to identify the specific field name, which could be 'Team', 'Squad', or similar. Examples Team PhoenixCore ServicesUI/UX Avengers
	Component Component	A sub-section or functional area of a project to which the item belongs.
Description Components are used in Jira to group issues within a project into smaller, more manageable parts. This could represent a feature area like 'User Authentication', a technical layer like 'Backend API', or a module like 'Reporting'. Analyzing by component allows for a more granular view of the development process. It can help identify if certain parts of the application generate more bugs, have longer development cycles, or experience more rework, pointing to areas of technical debt or complexity. Why it matters Allows for segmenting the process by functional or technical areas of the product, helping to pinpoint which components are sources of delay or quality issues. Where to get This is the standard 'components' field within the 'fields' object of the Jira Issue API response. Examples User InterfaceDatabaseAPI GatewayAuthentication
	Event End Time EventEndTime	The timestamp when an activity or status was completed.
Description This attribute marks the completion time of an activity. It is the timestamp of the next activity in the sequence for a given case. While the 'EventTime' (StartTime) marks the beginning of an activity, the EventEndTime marks its end. The difference between these two timestamps is the processing time for that activity. This is crucial for calculating the 'Average Stage Processing Time' KPI and for building dashboards that analyze activity durations. Why it matters Defines the end point of an activity, making it possible to calculate the duration of each step in the process, which is essential for bottleneck analysis. Where to get This is a derived attribute. For a given event, its end time is the start time of the subsequent event for the same case. Examples 2023-10-26T12:30:00Z2023-11-15T18:00:15Z2024-01-05T11:45:00Z
	Fix Version FixVersion	The software version in which the development item was actually resolved and released.
Description The 'Fix Version' in Jira indicates the release that contains the completed work for an item. It marks the concrete outcome of the development effort. This attribute provides the actual release context, which can be compared against the 'PlannedReleaseVersion' to analyze delivery performance. It is also used to group all items delivered in a specific release for a consolidated view of what was accomplished. Why it matters Confirms which release a piece of work was included in, providing the ground truth for release analysis and tracking delivered features. Where to get This corresponds to the 'fixVersions' field in the Jira Issue API response. Examples v2.1.1 Hotfixv3.0.0 Major Releasev2.2.0
	Handoff Wait Time HandoffWaitTime	The idle time between two consecutive activities.
Description This metric calculates the waiting time or queue time between the completion of one activity and the start of the next. It represents the time work is sitting idle waiting for someone to pick it up. This is a critical metric for the 'Average Handoff Wait Time' KPI and the 'Inter-Phase Handoff Efficiency' dashboard. High handoff times often indicate coordination problems, resource constraints, or inefficient communication between teams, such as between development and QA. Minimizing this idle time is a key lever for reducing the overall cycle time. Why it matters Highlights idle or queue time in the process, exposing inefficiencies in handoffs between teams or individuals and revealing coordination issues. Where to get This is a calculated metric. It is the start time of an activity minus the end time of the previous activity for the same case. Examples 017280043200
	Is Rework IsRework	A flag indicating if an activity is part of a rework loop.
Description This boolean attribute is true if an activity represents a step backward in the process, such as returning to 'Development Started' after failing QA testing. It is determined by analyzing the sequence of activities for a case. Identifying rework is fundamental to improving process efficiency and quality. This attribute directly supports the 'Rework Activity Rate' KPI and the 'Rework Loop Frequency and Paths' dashboard. It allows for quantifying the amount of wasted effort and pinpointing the root causes of quality issues that lead to rework. Why it matters Explicitly flags activities that are part of inefficient rework loops, allowing for precise measurement and analysis of process waste and quality issues. Where to get This is a calculated attribute. It requires defining the expected process flow and then flagging any activity that deviates by moving to an earlier stage. Examples truefalse
	Item Resolution ItemResolution	The final outcome or reason for closing a development item.
Description Resolution explains why an item was moved to a closed state. While a status might be 'Closed', the resolution could be 'Done', 'Won't Do', 'Duplicate', or 'Cannot Reproduce'. This provides crucial context on the outcome of the work. Analyzing resolution helps differentiate between successfully completed work and items that were canceled or rejected. This is important for quality analysis and understanding the true throughput of valuable work versus effort spent on items that were ultimately discarded. Why it matters Distinguishes between successfully completed items and those closed for other reasons, which is vital for accurate productivity and quality analysis. Where to get This is the 'resolution' field within the 'fields' object of the Jira Issue API response. It is typically populated only when an issue is closed. Examples DoneWon't DoDuplicateCannot Reproduce
	Planned Release PlannedReleaseVersion	The target software version or release in which the item is planned to be deployed.
Description This attribute, often the 'Affects Version/s' field in Jira, indicates the intended release for a feature or fix. It serves as a deadline or target for the completion of the work. This is a critical attribute for the 'On-Time Release Delivery Rate' KPI. By comparing the actual deployment date with the planned release date associated with this version, you can measure schedule adherence and the predictability of your release process. Why it matters Defines the target delivery date or release, enabling the calculation of on-time delivery rates and analysis of schedule adherence. Where to get This corresponds to the 'versions' or 'fixVersions' fields in the Jira Issue API. The specific field used for planning may vary. Examples Version 2.1Q1 2024 ReleaseProject Phoenix Launch
	Processing Time ProcessingTime	The total active time spent on a specific activity.
Description Processing Time is the duration an item spends in a particular status or activity. It is calculated as the difference between the EventEndTime and EventTime for a single event in the log. This metric is a core component of bottleneck analysis and is used directly in the 'Average Stage Processing Time' KPI. By aggregating the processing time for each activity, you can clearly see which stages of the development lifecycle consume the most time, helping to focus improvement efforts. Why it matters Directly measures the duration of each activity, making it a primary metric for identifying which process steps are the most time-consuming bottlenecks. Where to get This is a calculated metric, derived by subtracting the 'EventTime' from the 'EventEndTime' for each row in the event log. Examples 86400360000604800
	Reporter Reporter	The user who originally created or reported the development item.
Description The Reporter is the individual who created the issue in Jira. This could be a developer, a QA tester, a product manager, or even a customer via a service desk integration. Analyzing the reporter can provide insights into the origin of work. For example, you can analyze if bugs reported by the QA team have a different lifecycle than those reported by customers. It can also help in understanding communication patterns and the flow of information at the start of the process. Why it matters Identifies the origin of the work item, which can be used to analyze patterns based on who creates tasks or reports bugs. Where to get This is the 'reporter' field within the 'fields' object of the Jira Issue API response. Examples Charles DarwinMarie CurieIsaac Newton
	Sprint Name SprintName	The name of the agile sprint to which the development item is assigned.
Description For teams using Scrum, the Sprint is a time-boxed period during which a set of work is completed. This attribute captures the name or identifier of the sprint an item belongs to. Analyzing by sprint is fundamental for agile-focused process mining. It helps in evaluating the performance of individual sprints, understanding carry-over work, and tracking progress against sprint goals. It provides a time-based context that is more specific than general date ranges. Why it matters Provides a critical context for agile teams, enabling analysis of process efficiency and throughput on a sprint-by-sprint basis. Where to get This information is typically stored in a 'Sprint' custom field, managed by Jira Software (Agile). The data is accessible via the Issue API. Examples PROJ Sprint 1Q4-2023 Sprint 3November PI Sprint 2
	Total Cycle Time CycleTime	The total end-to-end duration for a development item.
Description Cycle Time measures the total time elapsed from the creation of a development item to its final resolution, such as deployment to production. It is calculated at the case level as the difference between the timestamp of the very first event and the very last event. This is a primary KPI for measuring overall process velocity and efficiency. The 'Average End-to-End Cycle Time' KPI and the 'Overall SDLC Cycle Time Analysis' dashboard are directly based on this calculation. Reducing cycle time is often a key goal of process improvement initiatives. Why it matters Measures the end-to-end speed of the development process, providing a key performance indicator for overall efficiency and delivery velocity. Where to get This is a calculated attribute at the case level. It is the timestamp of the last event minus the timestamp of the first event for a given 'DevelopmentItem'. Examples 12096002592000604800

Required Recommended Optional

Software Development Lifecycle Activities

These are the key process steps and milestones to capture in your event log for accurate Software Development Lifecycle process discovery.

6 Recommended 8 Optional

	Activity	Description
	Deployed To Production	This event marks the moment the code changes associated with the development item are live in the production environment. This can be inferred from a final status change to 'Done' or 'Released', or captured via an explicit event from an integrated CI/CD tool.
Why it matters This is the primary success endpoint for the process. It is essential for calculating the total end-to-end cycle time and measuring deployment frequency and throughput. Where to get Can be inferred from the Jira issue changelog when the status changes to 'Released' or 'Done'. For more accuracy, it can be captured from deployment events pushed by CI/CD tools like Jenkins, Bamboo, or via the Deployments feature in Jira. Capture Timestamp of status change to 'Done' or 'Released'. Event type inferred
	Development Item Created	This marks the beginning of the lifecycle, when a new development item, such as a story, bug, or task, is formally logged in Jira. This event is explicitly captured by the system with a creation timestamp for every issue.
Why it matters This activity serves as the definitive start of the process, which is essential for calculating end-to-end cycle times and tracking the total volume of incoming work. Where to get This is a fundamental event for every Jira issue. The creation timestamp is stored in the 'created' field of the issue record, accessible via the Jira API. Capture The 'created' timestamp field on the Jira Issue object. Event type explicit
	Development Started	Represents the moment a developer begins actively working on the development item. This is almost always captured by inferring a status change within Jira's workflow, for instance, when the issue status moves to 'In Progress'.
Why it matters This is a crucial milestone for measuring active development time. It helps distinguish between waiting time and value-adding work, a key metric for identifying bottlenecks. Where to get Inferred from the Jira issue changelog. It is the timestamp when the 'status' field first changes to 'In Progress', 'In Development', or a similar active state. Capture Timestamp of status change to 'In Progress'. Event type inferred
	QA Testing Completed	Signifies that the development item has successfully passed all Quality Assurance checks and is ready for the next stage, such as User Acceptance Testing or release. This is inferred from a status change out of the primary testing status.
Why it matters This marks the completion of an important quality gate. Analyzing the duration of the QA phase helps optimize testing processes and resource allocation. Where to get Inferred from the Jira issue changelog. It is the timestamp when the 'status' field transitions from 'In QA' to a subsequent state like 'Ready for UAT' or 'Ready for Release'. Capture Timestamp of status change from 'In QA' to 'Ready for UAT'. Event type inferred
	QA Testing Started	This event marks the beginning of the formal Quality Assurance testing phase for the development item. It is inferred from a Jira status change when the issue is moved to a status like 'In QA', 'In Testing', or 'Ready for Testing'.
Why it matters This is a key milestone that begins the quality validation cycle. Measuring the time from 'Development Completed' to this point highlights handoff delays between Dev and QA teams. Where to get Inferred from the Jira issue changelog. It's the timestamp when the 'status' field changes to a designated QA testing state like 'In QA'. Capture Timestamp of status change to 'In QA' or 'In Testing'. Event type inferred
	UAT Approved	Represents the successful completion of User Acceptance Testing, indicating stakeholder approval for release. This is inferred from a status change from 'In UAT' to a state like 'Ready for Release' or 'Done'.
Why it matters This milestone confirms business acceptance and greenlights the item for production deployment. It is a critical gate for ensuring the delivered work meets user expectations. Where to get Inferred from the Jira issue changelog. It is the timestamp of the status change from 'In UAT' to the next state in the workflow, signifying approval. Capture Timestamp of status change from 'In UAT' to 'Ready for Release'. Event type inferred
	Code Review Performed	Indicates that a peer or lead has reviewed the code for quality, standards, and functionality. This can be inferred from a status change, such as moving from 'In Review' to 'Ready for QA', or explicitly from integrated development tools.
Why it matters This activity is a critical quality gate. Analyzing its duration and outcomes, like rework, helps improve code quality and reduce bugs found later in the process. Where to get Commonly inferred from the Jira issue changelog when the status moves out of a 'Code Review' state. It can also be an explicit event if code repository tools like Bitbucket or GitHub are integrated. Capture Timestamp of status change from 'In Review' to the next state. Event type inferred
	Development Completed	This activity signifies that the developer has finished coding and the item is ready for the next stage, such as code review or testing. It is inferred from a Jira status change, like moving from 'In Progress' to 'In Review' or 'Ready for QA'.
Why it matters This marks the end of the core development phase, allowing for analysis of coding duration and the efficiency of handoffs to the quality assurance team. Where to get Inferred from the Jira issue changelog by capturing the timestamp when the 'status' field changes from an active development state to a subsequent state like 'In Review' or 'Ready for QA'. Capture Timestamp of status change from 'In Progress' to 'In Review' or 'Ready for QA'. Event type inferred
	Development Item Canceled	Represents the termination of a development item before completion. This is inferred from a status change to a terminal state like 'Canceled', 'Rejected', or 'Won't Do', and is often accompanied by a specific resolution.
Why it matters This activity tracks non-successful process outcomes. Analyzing why items are canceled can reveal issues with planning, prioritization, or requirement definition. Where to get Inferred from the Jira issue changelog. This is the timestamp when the issue 'status' is changed to 'Canceled' or 'Won't Do' and a corresponding resolution is set. Capture Timestamp of status change to 'Canceled', 'Rejected', or 'Won't Do'. Event type inferred
	Development Item Closed	This is the final administrative action, confirming that no further work is expected on the item. It is often inferred from a status change to 'Closed' and the setting of a 'Resolution' field value.
Why it matters Represents the absolute end of an item's journey. Comparing this with 'Deployed to Production' can reveal administrative lag or post-deployment monitoring periods. Where to get Inferred from the Jira issue changelog. It is the timestamp when the 'status' field changes to 'Closed' and a resolution is set. Capture Timestamp of status change to 'Closed'. Event type inferred
	Item Ready for Development	Indicates that a development item has been fully specified, reviewed, and prioritized, making it ready for a developer to start working on. This is typically inferred from a status change in the workflow, such as moving from 'Backlog' to 'To Do' or 'Ready for Dev'.
Why it matters Tracking this helps measure backlog readiness and the time items wait before development begins. It isolates planning and refinement time from active development time. Where to get Inferred from the Jira issue changelog. Look for a timestamp when the 'status' field changes to a value like 'Ready for Dev', 'To Do', or 'Selected for Development'. Capture Timestamp of status change to a pre-development ready state. Event type inferred
	Prepared For Release	Indicates the development item has passed all checks and has been bundled into a specific software release version, awaiting deployment. This is often inferred when an issue's status changes to 'Ready for Release' or the 'Fix Version' field is populated.
Why it matters This activity helps track release readiness and the time items spend waiting for a deployment window after all development and testing work is complete. Where to get Typically inferred from the Jira issue changelog as a status change to 'Ready for Release'. Alternatively, it can be inferred from the timestamp when the 'Fix Version/s' field is set. Capture Timestamp of status change to 'Ready for Release' or when 'Fix Version' is populated. Event type inferred
	QA Testing Failed	Indicates that the QA team found a defect, causing the development item to be sent back to developers for rework. This is inferred from a backward status transition, for example, from 'In QA' back to 'In Progress' or 'To Do'.
Why it matters This activity is crucial for identifying rework loops. Tracking its frequency helps quantify the cost of poor quality and highlights areas for improvement in development or requirements. Where to get Inferred from the Jira issue changelog. Captured when the 'status' field transitions from a testing state (e.g., 'In QA') to an earlier development state (e.g., 'In Progress'). Capture Timestamp of status change from a testing status to a development status. Event type inferred
	UAT Started	Marks the start of User Acceptance Testing, where business stakeholders or end-users validate the new functionality. This is inferred from a Jira status change to a state such as 'In UAT' or 'User Acceptance Testing'.
Why it matters This activity tracks the start of the final validation phase before release. Analyzing its duration is key to understanding and reducing delays caused by stakeholder availability or feedback cycles. Where to get Inferred from the Jira issue changelog. It's the timestamp when the 'status' field is updated to 'In UAT' or a similar designated status. Capture Timestamp of status change to 'In UAT'. Event type inferred

Recommended Optional

Extraction Guides

How to get your data from Jira Software

Steps

Log in to your Jira Software instance.
In the main navigation bar, select Issues and then click Search for issues. This will open the Issue Navigator.
On the search page, switch from the default Basic search to Advanced search to enable the use of Jira Query Language (JQL).
In the JQL query bar, enter the provided JQL query. Replace the placeholder values for the project key and the date range to match your specific requirements.
Execute the query by clicking the search icon or pressing Enter. This will display a list of all development items that match your criteria.
In the top right corner of the search results page, click the Export icon (it may look like a share icon or be labeled explicitly) and select the XML option. Do not use CSV, as the XML format contains the complete, structured changelog history needed for event log creation.
Save the downloaded XML file to your local machine. This file contains one record for each Jira issue but includes all historical changes nested within it.
Important Transformation Step: The exported XML file is not a flat event log. You must use an external script or an ETL tool to parse this file. The script needs to iterate through each <item> tag (representing a Jira issue) in the XML.
For each issue, the script must first generate a row for the Development Item Created activity using the created field's timestamp.
Next, the script must parse the <changelog> data within each issue. For each <changeitem> that represents a status transition, generate a new row in your output file. Map the Jira status transition (e.g., from 'In Progress' to 'In Review') to the corresponding business activity (e.g., 'Development Completed') and use the transition's timestamp for the EventTime.
The script should populate all required and recommended attributes for each row, extracting data like issue key, issue type, assignee, and project from the XML structure.
After processing all issues and their histories, save the transformed data as a CSV file with headers matching the specified attributes, ready for upload into the process mining tool.

Configuration

JQL Query Filters: The JQL query is the primary tool for selecting data. Key filters include project to target specific development projects, issuetype to include only relevant items like Story, Bug, or Task, and created to define the time window for the analysis.
Date Range: For initial analysis, it is recommended to extract data for a period of 3 to 6 months. This provides enough data for meaningful patterns while keeping the export file size manageable. Specify the range using created >= 'YYYY-MM-DD' and created <= 'YYYY-MM-DD' in your JQL.
Issue Types: Be specific about the issuetype values. Often, you will want to include Story, Bug, Task, and Spike but exclude container issues like Epic or granular ones like Sub-task if they do not represent the primary case.
Export Format: You must select XML as the export format. The standard CSV export does not reliably contain the structured changelog data required to reconstruct the sequence of activities.
User Permissions: The user performing the export must have 'Browse Projects' permission for the Jira projects specified in the JQL query.

a Sample Query config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Steps

Establish Database Connection: Ensure you have read-only access credentials and network connectivity to the Jira instance's backend SQL database. This method is only for self-hosted Jira installations.
Connect with a SQL Client: Use a database client tool like DBeaver, SQL Server Management Studio, or pgAdmin to connect to the Jira database using the provided credentials.
Identify Workflow Statuses: Before running the query, navigate to your Jira project's workflow settings (Project settings > Workflows). Carefully note the exact names of the statuses that correspond to each activity you need to track, for example, 'Backlog', 'In Progress', 'In Review', 'Done'.
Customize the SQL Query: Copy the provided SQL query into your client. You must customize the placeholder values. Pay close attention to the status names in the WHERE clauses for each UNION ALL block, as these must match your project's workflow exactly.
Set Query Parameters: Modify the date range filter (WHERE ji.created >= '2023-01-01') to define the period you want to analyze. It is also highly recommended to filter by one or more specific projects by uncommenting and setting the project key filter (--AND p.pkey IN ('PROJ1', 'PROJ2')).
Configure Custom Fields: Identify the custom field ID for 'Team Name' in your Jira instance. You can find this by navigating to Jira's Custom Fields administration page. Replace the placeholder 'customfield_10100' in the query with your actual ID.
Execute the Query: Run the modified SQL query against the Jira database.
Review the Output: Briefly inspect the returned data to ensure it contains rows for various activities and the columns are populated as expected.
Export the Event Log: Export the complete result set from your SQL client to a CSV file. Ensure the file encoding is UTF-8.
Prepare for Upload: Verify that the column headers in the exported CSV file match the required attribute names: DevelopmentItem, Activity, EventTime, SourceSystem, LastDataUpdate, Assignee, ItemType, ItemPriority, ItemStatus, ProjectName, and TeamName.

Configuration

Database Credentials: A read-only user account for the Jira database is required to prevent accidental data modification.
Workflow Status Names: The core of the query relies on filtering by status names (e.g., 'In Progress', 'Done'). These are specific to each Jira workflow and project. You must replace the placeholder values in the query with the exact names from your configuration.
Date Range: The query includes a WHERE ji.created >= '[YYYY-MM-DD]' clause to limit the amount of data processed. For initial analysis, a range of 3 to 6 months is recommended to ensure manageable data volume and faster query execution.
Project Filter: To focus the analysis, it is strongly advised to filter on specific project keys using the p.pkey IN ('[YourProjectKey]') condition. Querying all projects in a large Jira instance can be very slow.
Team Custom Field: The 'Team Name' is assumed to be a custom field. The provided query uses a placeholder ID (customfield_10100) which must be updated to match the correct ID from your Jira instance's configuration.
Performance: Direct database queries can be resource-intensive. Run this extraction during off-peak hours or, preferably, against a read-replica of the production database to avoid impacting Jira's performance for users.

a Sample Query sql

WITH EventLogBase AS (
    SELECT
        p.pkey || '-' || ji.issuenum AS DevelopmentItem,
        au.display_name AS Assignee,
        it.pname AS ItemType,
        pr.pname AS ItemPriority,
        p.pname AS ProjectName,
        (SELECT cfv.stringvalue FROM customfieldvalue cfv JOIN customfield cf ON cfv.customfield = cf.id WHERE cf.cfname = 'Team' AND cfv.issue = ji.id LIMIT 1) AS TeamName,
        ji.created AS created_timestamp,
        cg.created AS change_timestamp,
        ci.fieldtype,
        ci.field,
        ci.oldstring,
        ci.newstring,
        s.pname as CurrentItemStatus
    FROM jiraissue ji
    LEFT JOIN project p ON ji.project = p.id
    LEFT JOIN issuetype it ON ji.issuetype = it.id
    LEFT JOIN priority pr ON ji.priority = pr.id
    LEFT JOIN issuestatus s ON ji.issuestatus = s.id
    LEFT JOIN app_user au ON ji.assignee = au.user_key
    LEFT JOIN changegroup cg ON cg.issueid = ji.id
    LEFT JOIN changeitem ci ON ci.groupid = cg.id
    WHERE ji.created >= '2023-01-01' --<<< Set your desired start date here
    --AND p.pkey IN ('PROJ1', 'PROJ2') --<<< Uncomment and set your project keys here
)
-- 1. Development Item Created
SELECT
    b.DevelopmentItem,
    'Development Item Created' AS Activity,
    b.created_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.CurrentItemStatus AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM (
    SELECT DISTINCT DevelopmentItem, created_timestamp, Assignee, ItemType, ItemPriority, CurrentItemStatus, ProjectName, TeamName
    FROM EventLogBase
) b

UNION ALL

-- 2. Item Ready for Development
SELECT DISTINCT
    b.DevelopmentItem,
    'Item Ready for Development' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'Backlog' AND b.newstring = 'To Do' --<<< Adjust status names

UNION ALL

-- 3. Development Started
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 4. Development Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Progress' AND b.newstring = 'In Review' --<<< Adjust status names

UNION ALL

-- 5. Code Review Performed
SELECT DISTINCT
    b.DevelopmentItem,
    'Code Review Performed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In Review' AND b.newstring = 'Ready for QA' --<<< Adjust status names

UNION ALL

-- 6. QA Testing Started
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In QA' --<<< Adjust status names

UNION ALL

-- 7. QA Testing Failed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Failed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'In Progress' --<<< Adjust status names

UNION ALL

-- 8. QA Testing Completed
SELECT DISTINCT
    b.DevelopmentItem,
    'QA Testing Completed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In QA' AND b.newstring = 'Ready for UAT' --<<< Adjust status names

UNION ALL

-- 9. UAT Started
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Started' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'In UAT' --<<< Adjust status names

UNION ALL

-- 10. UAT Approved
SELECT DISTINCT
    b.DevelopmentItem,
    'UAT Approved' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.oldstring = 'In UAT' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 11. Prepared For Release
SELECT DISTINCT
    b.DevelopmentItem,
    'Prepared For Release' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Ready for Release' --<<< Adjust status names

UNION ALL

-- 12. Deployed To Production
SELECT DISTINCT
    b.DevelopmentItem,
    'Deployed To Production' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Released' --<<< Adjust status names

UNION ALL

-- 13. Development Item Closed
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Closed' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring = 'Closed' --<<< Adjust status names

UNION ALL

-- 14. Development Item Canceled
SELECT DISTINCT
    b.DevelopmentItem,
    'Development Item Canceled' AS Activity,
    b.change_timestamp AS EventTime,
    'Jira SQL' AS SourceSystem,
    CURRENT_TIMESTAMP AS LastDataUpdate,
    b.Assignee,
    b.ItemType,
    b.ItemPriority,
    b.newstring AS ItemStatus,
    b.ProjectName,
    b.TeamName
FROM EventLogBase b
WHERE b.field = 'status' AND b.newstring IN ('Canceled', 'Won''t Do', 'Rejected'); --<<< Adjust status names

Steps

Prerequisites: Ensure you have Python 3 installed on your system. Install the necessary libraries, requests for making API calls and pandas for data manipulation, by running the command: pip install requests pandas.
Generate a Jira API Token: Log in to your Jira instance. Navigate to your user profile settings, then go to Security and select 'Create and manage API tokens'. Create a new token and copy it securely. This token will be used instead of a password for script authentication.
Configure the Python Script: Copy the provided Python script into a file, for example, extract_jira_log.py. Open the file and update the configuration section at the top with your Jira site URL, your email address, and the API token you just generated.
Define the JQL Query: Modify the JQL_QUERY variable in the script. This query defines the scope of issues to be extracted. A good starting point is to filter by project, issue type, and a specific date range, for example: project = "MyProject" AND issuetype in (Story, Bug, Task) AND updated >= -180d.
Customize the Status Mapping: Review the STATUS_MAPPING dictionary in the script. This mapping is critical as it translates your organization's specific Jira workflow statuses into the standardized activities for process mining. You must update the keys, which are the Jira status names, to match your workflow exactly.
Execute the Script: Run the script from your terminal using the command: python extract_jira_log.py. The script will connect to the Jira API, fetch the issue data, and process the changelogs.
Handle API Pagination: The script automatically handles pagination by fetching issues in batches of 50. It will continue making requests until all issues matching the JQL query have been retrieved.
Process Issue Changelogs: For each issue, the script retrieves its entire history. It identifies the creation event and then iterates through all status changes, creating a new row in the event log for each relevant transition based on your STATUS_MAPPING.
Generate the Event Log File: Once all issues are processed, the script compiles the events into a pandas DataFrame, adds required metadata columns like SourceSystem and LastDataUpdate, and saves the final event log as a CSV file named jira_event_log.csv in the same directory.

Configuration

JIRA_URL: The base URL for your Jira instance, for example, https://your-company.atlassian.net.
JIRA_EMAIL: The email address of the user account that will be used for authentication.
JIRA_API_TOKEN: The API token generated from the Jira user's security settings for script authentication.
JQL_QUERY: The Jira Query Language string that filters which issues are extracted. It is highly recommended to filter on a date range, such as the last 6-12 months, to manage the data volume. You should also filter by project and the relevant issue types (e.g., Story, Bug, Task) to ensure you are analyzing the correct process.
STATUS_MAPPING: A Python dictionary that maps your specific Jira workflow status names to the required generic activity names. This is the most important configuration for ensuring the accuracy of the process model. You must customize this to match your project's workflow.
Prerequisites: The script requires a Jira user account with read access to the projects and issues being extracted. The user must have permissions to use the REST API.

a Sample Query python

import requests
import pandas as pd
from requests.auth import HTTPBasicAuth
from datetime import datetime, timezone
import json

class=class="hl-string">"hl-comment"># --- CONFIGURATION SECTION ---
class=class="hl-string">"hl-comment"># Replace with your Jira instance details
JIRA_URL = class="hl-string">"https://[your-company].atlassian.net"
JIRA_EMAIL = class="hl-string">"[your-email@example.com]"
JIRA_API_TOKEN = class="hl-string">"[your-jira-api-token]"

class=class="hl-string">"hl-comment"># JQL query to select the issues for extraction
class=class="hl-string">"hl-comment"># Best practice: Filter by project, issue type, and a date range
JQL_QUERY = class="hl-string">'project = "PROJ" AND issuetype in (Story, Bug, Task) AND updated >= -180d'

class=class="hl-string">"hl-comment"># --- STATUS MAPPING ---
class=class="hl-string">"hl-comment"># CRITICAL: Customize this mapping to match your Jira workflow statuses.
class=class="hl-string">"hl-comment"># The key is the Jira status name (case-sensitive) and the value is the desired Activity name.
STATUS_MAPPING = {
    class=class="hl-string">"hl-comment"># Example Mappings - Adjust to your workflow
    class="hl-string">'To Do': class="hl-string">'Item Ready for Development',
    class="hl-string">'In Progress': class="hl-string">'Development Started',
    class="hl-string">'In Review': class="hl-string">'Development Completed',
    class="hl-string">'Code Review': class="hl-string">'Code Review Performed', class=class="hl-string">"hl-comment"># Often combined with class="hl-string">'In Review' -> class="hl-string">'In QA' transition
    class="hl-string">'In QA': class="hl-string">'QA Testing Started',
    class="hl-string">'QA In Progress': class="hl-string">'QA Testing Started',
    class="hl-string">'Done from QA to In Progress': class="hl-string">'QA Testing Failed', class=class="hl-string">"hl-comment"># Special case for backward transitions
    class="hl-string">'UAT': class="hl-string">'UAT Started',
    class="hl-string">'Ready for Release': class="hl-string">'Prepared For Release',
    class="hl-string">'Done': class="hl-string">'Deployed To Production', class=class="hl-string">"hl-comment"># Often corresponds to final class="hl-string">'Done' state
    class="hl-string">'Released': class="hl-string">'Deployed To Production',
    class="hl-string">'Closed': class="hl-string">'Development Item Closed',
    class="hl-string">'Canceled': class="hl-string">'Development Item Canceled',
    class="hl-string">'Won\'t Doclass="hl-string">': 'Development Item Canceled',
    class=class="hl-string">"hl-comment"># Transitions to specific activities
    class="hl-string">'transition_In Review_to_In QA': class="hl-string">'Code Review Performed',
    class="hl-string">'transition_In QA_to_Ready for Release': class="hl-string">'QA Testing Completed',
    class="hl-string">'transition_UAT_to_Ready for Release': class="hl-string">'UAT Approved',
}

def get_team_from_issue(issue_fields):
    class=class="hl-string">"hl-comment"># Placeholder function to extract Team Name.
    class=class="hl-string">"hl-comment"># Customize this based on how team information is stored in your Jira.
    class=class="hl-string">"hl-comment"># Common sources are Components, Labels, or a custom field.
    if class="hl-string">'components' in issue_fields and issue_fields[class="hl-string">'components']:
        return issue_fields[class="hl-string">'components'][0][class="hl-string">'name']
    return None

def extract_jira_event_log():
    class="hl-string">"""Extracts an event log from Jira based on a JQL query."""
    auth = HTTPBasicAuth(JIRA_EMAIL, JIRA_API_TOKEN)
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json"
    }
    search_url = fclass="hl-string">"{JIRA_URL}/rest/api/3/search"

    event_log = []
    start_at = 0
    max_results = 50
    total_issues = 1 class=class="hl-string">"hl-comment"># Initialize to enter loop

    while start_at < total_issues:
        params = {
            class="hl-string">'jql': JQL_QUERY,
            class="hl-string">'startAt': start_at,
            class="hl-string">'maxResults': max_results,
            class="hl-string">'expand': class="hl-string">'changelog'
        }
        response = requests.get(search_url, headers=headers, params=params, auth=auth)
        response.raise_for_status() class=class="hl-string">"hl-comment"># Exit if the request fails
        data = response.json()

        total_issues = data[class="hl-string">'total']
        issues = data[class="hl-string">'issues']

        last_data_update = datetime.now(timezone.utc).isoformat()

        for issue in issues:
            issue_key = issue[class="hl-string">'key']
            fields = issue[class="hl-string">'fields']
            
            class=class="hl-string">"hl-comment"># Common attributes for all events of this issue
            common_attrs = {
                class="hl-string">'DevelopmentItem': issue_key,
                class="hl-string">'ItemType': fields.get(class="hl-string">'issuetype', {}).get(class="hl-string">'name'),
                class="hl-string">'ProjectName': fields.get(class="hl-string">'project', {}).get(class="hl-string">'name'),
                class="hl-string">'SourceSystem': class="hl-string">'Jira Software'
            }

            class=class="hl-string">"hl-comment"># 1. Development Item Created event
            created_time = pd.to_datetime(fields[class="hl-string">'created']).isoformat()
            event_log.append({
                **common_attrs,
                class="hl-string">'Activity': class="hl-string">'Development Item Created',
                class="hl-string">'EventTime': created_time,
                class="hl-string">'Assignee': fields.get(class="hl-string">'creator', {}).get(class="hl-string">'displayName'),
                class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                class="hl-string">'ItemStatus': class="hl-string">'Created',
                class="hl-string">'TeamName': get_team_from_issue(fields),
                class="hl-string">'LastDataUpdate': last_data_update
            })

            class=class="hl-string">"hl-comment"># Process changelog for status transitions
            if class="hl-string">'changelog' in issue and issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                for history in issue[class="hl-string">'changelog'][class="hl-string">'histories']:
                    event_time = pd.to_datetime(history[class="hl-string">'created']).isoformat()
                    author = history.get(class="hl-string">'author', {}).get(class="hl-string">'displayName')

                    for item in history[class="hl-string">'items']:
                        if item[class="hl-string">'field'] == class="hl-string">'status':
                            from_status = item[class="hl-string">'fromString']
                            to_status = item[class="hl-string">'toString']
                            activity = None

                            class=class="hl-string">"hl-comment"># Handle specific transitions first
                            transition_key = fclass="hl-string">"transition_{from_status.replace(' ', '')}_to_{to_status.replace(' ', '')}"
                            if transition_key in STATUS_MAPPING:
                                activity = STATUS_MAPPING[transition_key]
                            class=class="hl-string">"hl-comment"># Handle backward transitions (rework)
                            elif to_status == class="hl-string">'In Progress' and from_status in [class="hl-string">'In QA', class="hl-string">'QA In Progress', class="hl-string">'In Review']:
                                activity = class="hl-string">'QA Testing Failed'
                            class=class="hl-string">"hl-comment"># Handle general status changes
                            elif to_status in STATUS_MAPPING:
                                activity = STATUS_MAPPING[to_status]
                            
                            if activity:
                                event_log.append({
                                    **common_attrs,
                                    class="hl-string">'Activity': activity,
                                    class="hl-string">'EventTime': event_time,
                                    class="hl-string">'Assignee': author, class=class="hl-string">"hl-comment"># Person who made the change
                                    class="hl-string">'ItemPriority': fields.get(class="hl-string">'priority', {}).get(class="hl-string">'name'),
                                    class="hl-string">'ItemStatus': to_status,
                                    class="hl-string">'TeamName': get_team_from_issue(fields),
                                    class="hl-string">'LastDataUpdate': last_data_update
                                })
        
        start_at += len(issues)
        print(fclass="hl-string">"Processed {start_at} of {total_issues} issues...")

    if not event_log:
        print(class="hl-string">"No events were generated. Check your JQL query and STATUS_MAPPING.")
        return

    class=class="hl-string">"hl-comment"># Convert to DataFrame
    df = pd.DataFrame(event_log)

    class=class="hl-string">"hl-comment"># Ensure required columns are present
    required_cols = [class="hl-string">'DevelopmentItem', class="hl-string">'Activity', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate']
    recommended_cols = [class="hl-string">'Assignee', class="hl-string">'ItemType', class="hl-string">'ItemPriority', class="hl-string">'ItemStatus', class="hl-string">'ProjectName', class="hl-string">'TeamName']
    all_cols = required_cols + [col for col in recommended_cols if col in df.columns]
    df = df[all_cols]
    
    class=class="hl-string">"hl-comment"># Save to CSV
    df.to_csv(class="hl-string">'jira_event_log.csv', index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to jira_event_log.csv")

if __name__ == class="hl-string">"__main__":
    extract_jira_event_log()

Steps

Log in to your Jira Software instance.
In the main navigation bar, select Issues and then click Search for issues. This will open the Issue Navigator.
On the search page, switch from the default Basic search to Advanced search to enable the use of Jira Query Language (JQL).
In the JQL query bar, enter the provided JQL query. Replace the placeholder values for the project key and the date range to match your specific requirements.
Execute the query by clicking the search icon or pressing Enter. This will display a list of all development items that match your criteria.
In the top right corner of the search results page, click the Export icon (it may look like a share icon or be labeled explicitly) and select the XML option. Do not use CSV, as the XML format contains the complete, structured changelog history needed for event log creation.
Save the downloaded XML file to your local machine. This file contains one record for each Jira issue but includes all historical changes nested within it.
Important Transformation Step: The exported XML file is not a flat event log. You must use an external script or an ETL tool to parse this file. The script needs to iterate through each <item> tag (representing a Jira issue) in the XML.
For each issue, the script must first generate a row for the Development Item Created activity using the created field's timestamp.
Next, the script must parse the <changelog> data within each issue. For each <changeitem> that represents a status transition, generate a new row in your output file. Map the Jira status transition (e.g., from 'In Progress' to 'In Review') to the corresponding business activity (e.g., 'Development Completed') and use the transition's timestamp for the EventTime.
The script should populate all required and recommended attributes for each row, extracting data like issue key, issue type, assignee, and project from the XML structure.
After processing all issues and their histories, save the transformed data as a CSV file with headers matching the specified attributes, ready for upload into the process mining tool.

Configuration

JQL Query Filters: The JQL query is the primary tool for selecting data. Key filters include project to target specific development projects, issuetype to include only relevant items like Story, Bug, or Task, and created to define the time window for the analysis.
Date Range: For initial analysis, it is recommended to extract data for a period of 3 to 6 months. This provides enough data for meaningful patterns while keeping the export file size manageable. Specify the range using created >= 'YYYY-MM-DD' and created <= 'YYYY-MM-DD' in your JQL.
Issue Types: Be specific about the issuetype values. Often, you will want to include Story, Bug, Task, and Spike but exclude container issues like Epic or granular ones like Sub-task if they do not represent the primary case.
Export Format: You must select XML as the export format. The standard CSV export does not reliably contain the structured changelog data required to reconstruct the sequence of activities.
User Permissions: The user performing the export must have 'Browse Projects' permission for the Jira projects specified in the JQL query.

a Sample Query config

project = "[Your Project Key]" AND issuetype in (Story, Bug, Task) AND created >= "[Start Date in YYYY-MM-DD format]" AND created <= "[End Date in YYYY-MM-DD format]" ORDER BY created DESC

Your Software Development Lifecycle Data Template

Your Software Development Lifecycle Data Template

Software Development Lifecycle Attributes

Software Development Lifecycle Activities

Extraction Guides

Jira JQL Query with Built-in CSV or XML Export

Steps

Configuration

a Sample Query config

Direct Jira Database Query via SQL (Self-Hosted)

Steps

Configuration

a Sample Query sql

Python Script using the Official Jira REST API

Steps

Configuration

a Sample Query python

Real-time Event Streaming via Automation Webhooks

Steps

Configuration

a Sample Query config

Ready to Get Started?

Optimize Your SDLC in Jira Software, Start Today!

Your Software Development Lifecycle Data Template

Your Software Development Lifecycle Data Template

Software Development Lifecycle Attributes

Software Development Lifecycle Activities

Extraction Guides

Jira JQL Query with Built-in CSV or XML Export

Steps

Configuration

a Sample Query config

Direct Jira Database Query via SQL (Self-Hosted)

Steps

Configuration

a Sample Query sql

Python Script using the Official Jira REST API

Steps

Configuration

a Sample Query python

Real-time Event Streaming via Automation Webhooks

Steps

Configuration

a Sample Query config

We value your privacy

Ready to Get Started?

Optimize Your SDLC in Jira Software, Start Today!