Your Software Development Lifecycle Data Template

The Activity Name describes a specific step or status change in the development process. These activities form the nodes in the process map, representing key milestones like 'Item Approved for Development', 'Code Submitted for Review', or 'QA Testing Completed'.

This attribute is crucial for visualizing the process flow and understanding the sequence of events. By analyzing the different activities, teams can identify the most common paths, discover process deviations, and measure the time spent in various stages. It forms the basis for bottleneck analysis, rework detection, and conformance checking against a target process model.

It defines the steps in the process, allowing for the visualization and analysis of the development workflow.

Often derived from status change logs, event streams, or audit history tables associated with development work items.

The Development Item ID is the primary key that uniquely identifies each case instance throughout the software development lifecycle. Each ID represents a distinct piece of work, like a user story, task, or bug fix, from its creation to its final resolution or deployment.

In process mining analysis, this attribute is essential for reconstructing the end-to-end journey of every work item. It allows the tool to link all related activities, such as 'Development Started', 'Code Review Completed', and 'Deployed to Production', into a coherent process flow. Analyzing the lifecycle of individual development items helps identify variations, delays, and rework loops associated with specific pieces of work.

This is the fundamental case identifier required to trace the complete lifecycle of each development work item from beginning to end.

Typically found in the main work item or issue tracking tables of a software development management system.

The Event Start Time marks the exact date and time that an activity began. It provides the chronological order for all events within a single case, which is essential for reconstructing the process flow accurately.

Timestamps are the foundation of all time-based process mining analysis. They are used to calculate key performance indicators like cycle times, waiting times, and processing times between activities. Analyzing timestamps helps pinpoint bottlenecks, measure process efficiency, and understand the duration of different stages in the development lifecycle. For instance, the time between 'Code Submitted for Review' and 'Code Review Completed' can reveal delays in the review process.

This timestamp is essential for ordering events correctly and calculating all time-based metrics, such as cycle time and bottlenecks.

Available in event logs, audit trails, or history tables that record changes to development work items.

The Last Data Update attribute records the date and time when the data was most recently extracted or updated from the source system. This provides a clear indication of the data's freshness and relevance.

This information is vital for ensuring that analyses and dashboards are based on current information. Stakeholders can see at a glance how up-to-date the process view is, which builds confidence in the insights derived. It is a key piece of metadata for managing data pipelines and scheduling data refreshes.

Indicates the freshness of the data, ensuring that analysis is timely and relevant for decision-making.

This value is typically generated and stored by the data extraction, transformation, and loading (ETL) pipeline.

The Source System attribute identifies the originating application or platform where the development lifecycle data was recorded. This is particularly useful in environments where multiple development tools are used, for example, Jira for issue tracking and GitLab for source code management.

In analysis, specifying the source system helps in data validation and provides context for the process data. It allows for comparative analysis between processes managed in different systems and ensures that data interpretation is correct, as field names and process conventions can vary between systems. It can also be used to filter the analysis to a specific tool's data set.

Provides context about the data's origin, which is crucial for data validation and for analyses involving multiple integrated systems.

This is typically a static value added during the data extraction process to identify the origin of the records.

This attribute identifies the individual or group responsible for completing the current step or the overall work item. The assignee can change multiple times throughout the lifecycle, reflecting handoffs between different roles like developers, QA testers, and reviewers.

Analyzing the Assigned To attribute is key to understanding team workload, handoff efficiency, and collaboration patterns. It allows for filtering the process map to see the work of a specific person or team, helping to identify resource-specific bottlenecks. Social network analysis based on handoffs between assignees can reveal communication gaps or overly complex collaboration structures.

It enables analysis of resource workload, handoff frequency, and collaboration patterns, helping to optimize team efficiency.

Found in the work item or issue record, often tracked in the item's history or audit log.

The Priority attribute indicates the business or technical urgency of a work item. This is typically set to values like 'High', 'Medium', or 'Low' and helps teams decide what to work on next.

In process mining, priority is a powerful dimension for analysis. It allows teams to check if high-priority items are actually processed faster than low-priority ones. Comparing the cycle times across different priority levels can reveal if the process respects business priorities. If high-priority items are frequently delayed, it can point to issues in planning, resource allocation, or workflow design.

Helps verify if high-priority work moves faster through the process and identifies bottlenecks that disproportionately affect critical items.

A standard field on the work item or issue record in most development management systems.

The Development Item Status represents the state of a work item at a specific point in time. While the Activity Name captures the event of changing status, this attribute captures the state itself. This can be useful for analyzing the state of work at the time an event occurred.

This attribute is often used to create the Activity Name but can provide additional context. For instance, analyzing the status field allows for duration analysis of how long items spend in a particular state, such as 'Blocked' or 'Waiting for Review'. Understanding time spent in non-productive states is crucial for identifying systemic delays and improving flow efficiency.

It enables analysis of time spent in different states, helping to identify delays and time spent in non-value-adding statuses like 'Blocked'.

Available as a primary field on the work item or issue record and is tracked in its history log.

This attribute categorizes the nature of the work being performed. Different types of work items often follow different process paths and have different performance expectations. For example, a 'Bug' might require a rapid hotfix process, while a 'Feature' follows a standard development and testing cycle.

Using this attribute, analysts can compare the process flows and performance for different types of work. This helps answer questions like 'Is our bug-fixing process faster than our feature development process?' or 'Do technical debt items experience more rework?'. It is a fundamental dimension for segmenting the data to gain more specific and actionable insights.

Allows for comparing processes and performance across different work categories, revealing inefficiencies specific to certain types of development.

A standard field on the work item or issue record in most development management systems.

The Event End Time marks the conclusion of an activity. While many process steps are recorded as instantaneous events where the start and end times are identical, some activities have a measurable duration. For example, a 'Code Review' activity might have a distinct start and end time.

This attribute is essential for calculating the active processing time of specific tasks, distinguishing it from idle or waiting time. By comparing the duration between Event Start Time and Event End Time, analysts can measure the effort spent on value-adding activities. This enables a more granular analysis of resource utilization and helps identify which tasks are consuming the most active work time.

Enables the calculation of active processing time for individual activities, separating it from waiting time and providing a clearer view of effort.

Can be found in event logs or derived by taking the timestamp of the next activity in the sequence for the same work item.

The Project Name provides context by grouping work items that belong to a specific product, initiative, or codebase. Development practices and cycle times can vary significantly between projects, for example, a legacy system versus a new greenfield application.

This attribute allows for a high-level aggregation and comparison of development processes across different parts of the organization. By filtering the analysis by project, managers can assess the health and efficiency of each development effort. It is also essential for understanding how process performance relates to the specific context and technical environment of a project.

Allows for process analysis to be segmented by product or initiative, revealing performance differences related to project context.

A standard field on the work item or issue record, or the name of the repository in systems like Git.

This attribute identifies the specific team, squad, or group responsible for delivering the development item. In larger organizations, work is often distributed across multiple specialized teams like 'Frontend', 'Backend', 'Mobile', or 'Platform'.

Analyzing by Team Name allows for performance comparison and best practice sharing between teams. It helps answer questions like 'Which team has the shortest cycle time?' or 'Does one team experience more rework than others?'. This analysis can uncover differences in workflows, skill sets, or resource availability that impact overall delivery performance, providing opportunities for targeted process improvements.

Enables performance benchmarking between different teams, helping to identify best practices and areas for improvement.

Often associated with the assigned user or as a direct field on the project or work item record.

The Creator attribute identifies the person who initiated the work item. This could be a product manager creating a user story, a QA tester logging a bug, or a customer service agent reporting a customer issue.

Analyzing the creator of work items can provide insights into the sources of work. For example, a high volume of bugs reported by end-users might indicate quality issues in recent releases. It can also be used to analyze the clarity and quality of initial requirements by correlating the creator with downstream rework or delays.

Helps identify the originators of work, which can be analyzed to understand sources of demand, bugs, or feature requests.

A standard field like 'Reporter' or 'Author' on the initial creation record of a work item.

Severity is distinct from priority, it measures the technical impact of an issue, whereas priority measures the urgency of fixing it. For example, a typo on a rarely visited page might be low severity and low priority, while a critical data corruption issue would be high severity and high priority.

This attribute is crucial for quality analysis, especially when analyzing bug-fixing processes. It allows teams to assess whether they are effectively addressing the most severe issues first. By analyzing the cycle time for different severity levels, organizations can ensure that critical system problems are resolved quickly to minimize customer impact.

Enables analysis of how effectively the team addresses issues based on their technical impact, ensuring critical problems are resolved promptly.

A standard field, particularly for work items of type 'Bug' or 'Incident', in development management systems.

The Planned Release attribute links a development item to a specific delivery schedule or version. This is often used in release planning to batch features and fixes for a coordinated deployment.

Analyzing by Planned Release helps in assessing the predictability and reliability of the release process. It allows for tracking on-time delivery rates by comparing the planned release with the actual deployment date. Furthermore, it helps in managing scope and understanding the flow of work destined for a specific release, highlighting potential risks or delays that could impact the delivery timeline.

Connects development work to delivery schedules, enabling analysis of on-time delivery rates and release predictability.

A standard field such as 'Fix Version', 'Target Release', or 'Iteration Path' in agile planning and development tools.

The Rework Indicator is a derived boolean or categorical attribute that flags events as being part of a rework cycle. This is typically identified when the process flow moves backward, for instance, from 'QA Testing' back to 'Development in Progress', or when specific rework activities like 'Rework Identified in QA' occur.

This attribute is extremely valuable for quality and efficiency analysis. It allows for the direct calculation of rework rates and highlights the parts of the process that generate the most rework. By filtering for rework activities, teams can perform root cause analysis to understand why quality issues are not caught earlier. Reducing rework is a key lever for improving both development speed and product quality.

Directly quantifies rework, allowing teams to measure its frequency, analyze its causes, and track improvements in quality over time.

Typically derived during data transformation by identifying backward loops in the process flow or specific failure-related activity names.