Your Software Development Lifecycle Data Template

Azure DevOps
Your Software Development Lifecycle Data Template

Your Software Development Lifecycle Data Template

This template provides a clear roadmap for preparing your Software Development Lifecycle data for process mining. It outlines the essential data attributes you need to collect, the key activities to track, and provides practical guidance on how to extract this information specifically from Azure DevOps. Leverage this resource to ensure your data is perfectly structured for insightful analysis and process optimization.
  • Recommended attributes to collect
  • Key activities to track for your SDLC
  • Detailed extraction guidance for Azure DevOps
New to event logs? Learn how to create a process mining event log.

Software Development Lifecycle Attributes

These are the recommended data fields to include in your event log for comprehensive Software Development Lifecycle analysis and optimization.
5 Required 8 Recommended 6 Optional
Name Description
Activity Name
ActivityName
The name of the specific event or task that occurred at a point in time within the development lifecycle for a work item.
Description

The Activity Name describes a specific step or milestone in the process, such as 'Development Started', 'Pull Request Created', or 'Deployed to Production'. These activities are derived from changes to the work item's state, linked events like builds or pull requests, or custom events.

This attribute is essential for constructing the process map, which visually represents the workflow. It allows analysts to understand the sequence of events, identify common pathways, discover bottlenecks between specific activities, and analyze the frequency of each step.

Why it matters

It defines the steps in the process, forming the backbone of the process map and enabling analysis of workflow, bottlenecks, and deviations.

Where to get

This is typically derived from changes in the 'State' field of a work item, or from linked events like builds, commits, and pull requests. The Work Item History provides the raw data for these events.

Examples
Development StartedPull Request CompletedQA Testing FailedDeployed to ProductionWork Item Closed
Development Item
DevelopmentItem
The unique identifier for a single unit of work, such as a feature, bug, or user story, which serves as the case identifier for the process.
Description

The Development Item represents a distinct piece of work tracked within Azure DevOps. Each item, identified by its unique ID, is the central object around which all process activities revolve, from creation and planning through development, testing, and deployment.

In process mining analysis, this attribute is fundamental for correlating all related events into a single case journey. It allows for the reconstruction of the end-to-end lifecycle for each work item, enabling analysis of cycle times, process deviations, and rework loops on an individual item basis.

Why it matters

This is the core identifier that connects all process steps into a coherent case, making end-to-end analysis of the software development lifecycle possible.

Where to get

This corresponds to the 'ID' field of a Work Item in Azure DevOps Boards. It is accessible via the Azure DevOps REST API for Work Item Tracking.

Examples
10234102351023610237
Event Time
EventTime
The precise timestamp indicating when a specific activity or event occurred for a development item.
Description

Event Time captures the date and time of each activity in the development lifecycle. This timestamp is the fundamental temporal element used to order events chronologically and calculate durations between them.

In analysis, this attribute is critical for calculating all time-based metrics, including cycle times, processing times, and waiting times. It enables the creation of a time-ordered event log, which is the required input for any process mining analysis. It is used to diagnose delays, measure performance against SLAs, and track trends over time.

Why it matters

This timestamp provides the chronological order of events, which is essential for calculating all duration-based KPIs and understanding process flow and bottlenecks.

Where to get

This is the 'Changed Date' associated with each update in a work item's history. For external events like builds or deployments, it is the completion timestamp of that event.

Examples
2023-10-26T10:00:00Z2023-10-27T14:35:10Z2023-10-28T09:00:00Z
Last Data Update
LastDataUpdate
The timestamp indicating the last time the data for this process was refreshed from the source system.
Description

This attribute records when the dataset was last extracted and updated from Azure DevOps. It provides a clear indication of the data's freshness and the time frame covered by the analysis.

In any process analysis, knowing the recency of the data is critical for making informed decisions. This timestamp helps users understand if they are looking at real-time information or a historical snapshot, which affects the relevance of the findings.

Why it matters

It informs users about the freshness of the data, ensuring that analyses and decisions are based on an understood time frame.

Where to get

This is a metadata timestamp generated and stored during the data extraction, transformation, and loading (ETL) process.

Examples
2024-05-20T08:00:00Z
Source System
SourceSystem
The system from which the process data was extracted, which in this case is Azure DevOps.
Description

This attribute identifies the originating system for the data. It is particularly useful in environments where data from multiple systems is combined for a broader process view. For this specific model, the value is consistently Azure DevOps.

While it may seem static in a single-system analysis, it provides essential context about the data's origin, which is crucial for data governance, troubleshooting, and future integrations with other systems like ServiceNow or SAP.

Why it matters

It provides crucial context about the data's origin, which is important for data governance, validation, and multi-system process analysis.

Where to get

This is a static value that should be added during the data extraction and transformation process to label the dataset.

Examples
Azure DevOps
Assigned To
AssignedTo
The user or team member to whom the development item is currently assigned.
Description

This attribute identifies the individual responsible for the work item at a given stage of the process. The assignment can change multiple times throughout the item's lifecycle, for example, from a developer to a tester and then to a release manager.

Analyzing by 'Assigned To' is critical for the Developer and Tester Workload Overview dashboard. It helps in understanding resource allocation, identifying overloaded team members, and analyzing performance differences between individuals or teams.

Why it matters

It allows for resource-based analysis, helping to understand workload distribution, identify resource-specific bottlenecks, and manage team capacity.

Where to get

This corresponds to the 'Assigned To' field on a Work Item in Azure DevOps. The value is captured from the work item history for each event.

Examples
jane.doe@example.comjohn.smith@example.comunassigned
Development Cycle Time
DevelopmentCycleTime
The total time elapsed from the creation of a development item until its deployment to production.
Description

Development Cycle Time is a key performance indicator that measures the end-to-end duration of the development process for a single work item. It is calculated as the difference between the timestamp of the 'Deployed to Production' activity and the 'Work Item Created' activity.

This calculated metric is the primary KPI for the End-to-End Development Cycle Time dashboard and the Historical Cycle Time Trends. It provides a holistic measure of process velocity and efficiency, and tracking it over time shows the impact of process improvement initiatives.

Why it matters

This is a critical KPI that measures the overall speed and efficiency of the development process from start to finish.

Where to get

This is calculated by taking the timestamp of the final deployment event and subtracting the timestamp of the creation event for each case.

Examples
10 days 4 hours 30 minutes25 days 8 hours 0 minutes5 days 2 hours 15 minutes
End Time
EndTime
The timestamp indicating when an activity was completed. It is used to calculate the processing time of an activity.
Description

The End Time marks the conclusion of an activity. In many event logs, the start time of the next activity serves as the end time of the previous one. However, having a distinct end time allows for more accurate calculation of both activity processing time and the idle time between activities.

This attribute is crucial for calculating the ProcessingTime KPI and for performing detailed bottleneck analysis. It helps differentiate between the time spent actively working on a task versus the time spent waiting for the next step to begin, which is key for the Stage Handoff Analysis dashboard.

Why it matters

It enables the precise calculation of activity processing times and idle times, which is fundamental for bottleneck analysis and efficiency improvements.

Where to get

This is often derived. It can be the start time of the subsequent event for the same case, or it can be explicitly recorded if the source system captures both start and end times for tasks.

Examples
2023-10-26T18:00:00Z2023-10-27T15:00:00Z2023-10-28T11:00:00Z
Is Rework
IsRework
A boolean flag indicating whether a development item has re-entered a previous stage in its lifecycle.
Description

This flag is set to true if a work item exhibits a rework loop, for instance, moving from 'QA Testing Completed' back to 'Development Started'. It is calculated by analyzing the sequence of activities for a case and detecting non-linear progressions.

This attribute is essential for the Rework and Retesting Frequency dashboard and the Rework Loop Frequency KPI. It allows for easy filtering and quantification of rework, helping to pinpoint quality issues, communication gaps, or insufficient testing that lead to inefficiencies.

Why it matters

It directly identifies and quantifies rework, helping to highlight quality issues and process inefficiencies that extend cycle times.

Where to get

This is a calculated attribute derived by analyzing the sequence of activities in the event log for each case.

Examples
truefalse
Priority
Priority
A numerical or descriptive ranking of the development item's importance relative to other items.
Description

Priority indicates the scheduling importance of a work item. A higher priority suggests that an item should be addressed more quickly than lower-priority items. Common values are numerical, such as 1, 2, 3, 4, with 1 being the highest.

This attribute is essential for the Priority-Based Throughput & Cycle Time dashboard. Analyzing data with this attribute helps determine if the prioritization system is effective, meaning high-priority items actually move through the process faster than low-priority ones.

Why it matters

It allows analysis of whether the process effectively fast-tracks high-priority items, which is key to evaluating the success of prioritization strategies.

Where to get

This corresponds to the 'Priority' field on a Work Item in Azure DevOps.

Examples
1234
State
State
The current status of the development item within its workflow, such as 'New', 'Active', 'Resolved', or 'Closed'.
Description

The State attribute represents the formal status of a work item at any point in time, as defined by the project's process template. Transitions between these states are the primary source for generating the activities in the event log.

While the 'Activity' attribute is often a more descriptive version of a state change, the raw 'State' attribute is useful for filtering and analysis. It helps in understanding how much time items spend in particular states and is fundamental for building the Stage Duration dashboard and analyzing handoffs.

Why it matters

It indicates the work item's status in the lifecycle, which is fundamental for understanding process flow and calculating time spent in various stages.

Where to get

This corresponds to the 'State' field on a Work Item in Azure DevOps.

Examples
NewActiveIn QAResolvedClosed
Team Name
TeamName
The name of the development team responsible for the work item.
Description

The Team Name identifies the specific team that a work item is assigned to. In Azure DevOps, work is often organized by teams, which can be subsets of a larger project.

This attribute allows for process analysis to be segmented by team. It is invaluable for comparing processes and performance across different teams, identifying best practices in high-performing teams, and finding areas where specific teams may need support or process improvements.

Why it matters

It enables comparative analysis between different teams, helping to identify performance variations and share best practices across the organization.

Where to get

This is often derived from the 'Area Path' of a work item, as teams are typically mapped to specific area paths in Azure DevOps.

Examples
Team PhoenixOmega SquadPlatform CoreFrontend Crew
Work Item Type
WorkItemType
The classification of the development item, such as Bug, Feature, User Story, or Task.
Description

The Work Item Type categorizes the nature of the work being performed. Different types of work items often follow different process paths and have different performance expectations or SLAs. For example, a 'Bug' might follow an expedited path compared to a 'Feature'.

This attribute is essential for comparative analysis. It allows you to filter the process map or KPIs by the type of work to understand if certain processes are more efficient for bugs versus features, or to track historical cycle time trends for different categories of work.

Why it matters

It enables segmentation of the process analysis, allowing for comparison of workflows and performance for different categories of work like bugs and features.

Where to get

This corresponds to the 'Work Item Type' field on a Work Item in Azure DevOps.

Examples
BugFeatureUser StoryTask
Approval Waiting Time
ApprovalWaitingTime
The time a development item spends waiting for an approval after a request has been made.
Description

This metric measures the duration of specific waiting periods where a work item is pending an approval. A prime example is the time between 'UAT Started' and 'UAT Approved'. It is calculated by measuring the time between these two specific activities for a given case.

This calculated attribute directly supports the Approval Waiting Time Analysis dashboard and the corresponding KPI. By isolating these specific delays, teams can target communication and decision-making processes to reduce idle time and accelerate the overall lifecycle.

Why it matters

It specifically measures delays caused by waiting for decisions or approvals, highlighting opportunities to improve communication and decision-making processes.

Where to get

This is calculated by finding specific start and end approval activities in the event log (e.g., 'UAT Started' and 'UAT Approved') and calculating the time difference.

Examples
3 days 2 hours1 day 8 hours 30 minutes4 hours
Iteration Path
IterationPath
The development sprint or timebox to which the work item is assigned.
Description

The Iteration Path, or sprint, represents a specific time-boxed period of development. Work items are assigned to an iteration to be completed within that timeframe.

Analyzing by Iteration Path helps in understanding process performance on a sprint-by-sprint basis. It can be used to track if cycle times are improving over successive sprints, to analyze carry-over work, and to evaluate the predictability of sprint planning.

Why it matters

It allows for sprint-based analysis, helping teams to evaluate their performance over time and improve their agile practices.

Where to get

This corresponds to the 'Iteration Path' field on a Work Item in Azure DevOps.

Examples
E-Commerce Platform\Sprint 12E-Commerce Platform\Sprint 13Mobile App Relaunch\Phase 2\Sprint 4
Project Name
ProjectName
The name of the Azure DevOps project to which the development item belongs.
Description

This attribute identifies the specific project within the Azure DevOps organization where the work item is located. It provides high-level context, especially in organizations with many projects.

Project Name is a critical dimension for filtering and comparison. It supports the Historical Cycle Time Trends dashboard by allowing analysis to be segmented by project, revealing if certain projects are more or less efficient than others, or if process improvements in one project have had a positive impact.

Why it matters

It provides a high-level grouping for analysis, enabling performance comparison and trend analysis across different projects.

Where to get

This corresponds to the 'Team Project' field on a Work Item in Azure DevOps.

Examples
E-Commerce PlatformMobile App RelaunchData Warehouse Modernization
Pull Request ID
PullRequestId
The identifier of a pull request linked to the development item.
Description

This attribute links a work item to a specific pull request, which is the mechanism for submitting and reviewing code changes. A single work item may be associated with multiple pull requests.

Having the Pull Request ID allows for a more granular analysis of the code review and integration part of the lifecycle. It can be used to measure the time from pull request creation to completion, and to analyze how often pull requests are rejected or require significant changes, which can be an indicator of code quality or unclear requirements.

Why it matters

It connects development work to specific code review activities, enabling detailed analysis of the code integration and quality assurance process.

Where to get

This information is found in the 'Links' or 'Development' section of a work item in Azure DevOps.

Examples
452145334589
Severity
Severity
Indicates the impact of a bug or issue on the system or end-users.
Description

Severity is used to classify the impact of a bug, from critical system failures to minor cosmetic issues. This is distinct from priority, which dictates the order of work. A high-severity bug may have a low priority if it has a readily available workaround.

This attribute provides another dimension for analysis, particularly for the Priority-Based Throughput & Cycle Time dashboard. It allows for investigating questions like, 'Are we fixing the most critical bugs first?' and helps in understanding the risk profile of the work being processed.

Why it matters

It helps categorize work items by their business impact, enabling analysis of how effectively the team addresses high-impact issues.

Where to get

This corresponds to the 'Severity' field on a Work Item, typically for bugs, in Azure DevOps.

Examples
1 - Critical2 - High3 - Medium4 - Low
Stage Handoff Time
StageHandoffTime
The duration of idle time between the completion of one major stage and the start of the next.
Description

Stage Handoff Time measures the waiting period between sequential process stages, for example, the time between 'Development Completed' and 'QA Testing Started'. It is calculated by identifying these key transitions and measuring the time gap between the end of the first activity and the start of the second.

This metric is the focus of the Stage Duration and Handoff Analysis dashboard. Isolating and measuring handoff time is critical for identifying hidden bottlenecks where work is sitting idle, often due to resource unavailability, communication delays, or inefficient processes.

Why it matters

It quantifies waiting times between process stages, directly exposing hidden bottlenecks and delays that are not part of active work.

Where to get

This is a calculated attribute. It requires identifying pairs of sequential activities that represent a handoff and then calculating the time difference between them.

Examples
2 hours 15 minutes1 day 4 hours0 hours 30 minutes
Required Recommended Optional

Software Development Lifecycle Activities

These are the key process steps and milestones to capture in your event log for accurate process discovery and bottleneck identification.
7 Recommended 8 Optional
Activity Description
Deployed to Production
Marks the successful deployment of the work item's associated code to the production environment. This is an explicit event captured from Azure Pipelines release logs.
Why it matters

This is a critical milestone representing the delivery of value. It serves as the end point for calculating lead time and cycle time.

Where to get

Captured from Azure Pipelines release pipeline data, specifically the completion event of a deployment to a 'Production' stage that is linked to the work item.

Capture

Captured from a release pipeline deployment completion event.

Event type explicit
Development Started
This activity signifies that a developer has started actively working on the item. It is captured by inferring a change in the work item's state to 'Active', 'In Progress', or 'Committed'.
Why it matters

Marks the start of the active development phase. Analyzing the time from 'Created' to 'Development Started' reveals backlog queue times.

Where to get

Inferred from the work item history when the System.State field changes from a 'New' or 'Approved' state to an 'In Progress' state.

Capture

Inferred from State field changing to 'Active' or 'In Progress'.

Event type inferred
Pull Request Completed
Represents the successful completion of a code review, where the pull request is approved and the code is merged into the target branch. This event is explicitly logged in Azure Repos.
Why it matters

Marks the end of the code review phase, a common bottleneck. Analyzing the time between PR creation and completion reveals review cycle efficiency.

Where to get

Captured from the completion or merge event of a pull request in Azure Repos that is linked to a work item.

Capture

Captured from the pull request merge event linked to a work item.

Event type explicit
Pull Request Created
Indicates that the developer has completed the initial coding and submitted the changes for review via a pull request. This event links the work item to a specific code change in Azure Repos.
Why it matters

This is a key handoff from development to code review. Tracking this helps measure the duration of coding and identifies when code is ready for peer review.

Where to get

Captured from Azure Repos data by linking the pull request creation event to its associated work item. This is often an explicit link made by the developer.

Capture

Captured from Azure Repos pull request creation event linked to a work item.

Event type explicit
QA Testing Started
Represents the start of the formal quality assurance testing phase. This activity is inferred when a work item's state is changed to 'In QA', 'Testing', or a similar value.
Why it matters

Marks the beginning of the QA cycle. Analyzing the duration of this phase is crucial for understanding testing bottlenecks and efficiency.

Where to get

Inferred from the work item history by tracking a change in the System.State field to 'In QA' or another designated testing state.

Capture

Inferred from State field changing to 'In QA' or 'Testing'.

Event type inferred
UAT Approved
This activity signifies that business stakeholders have approved the changes after User Acceptance Testing. It is typically inferred from a state change from 'In UAT' to 'UAT Approved' or 'Ready for Release'.
Why it matters

This is a critical approval milestone that confirms the work item meets business requirements and is ready for production deployment.

Where to get

Inferred from the work item history by detecting a change in the System.State field from a UAT state to an approved or release-ready state.

Capture

Inferred from State field changing from 'In UAT' to 'Ready for Release'.

Event type inferred
Work Item Created
This activity marks the beginning of the development lifecycle, representing the creation of a new work item such as a User Story, Bug, or Task. It is captured explicitly when a new record is saved in Azure DevOps Boards.
Why it matters

This is the primary start event for the process. It is essential for measuring the end-to-end development cycle time and understanding the initial sources of work.

Where to get

This event is captured from the 'Created Date' on the work item itself. The work item history table also records this initial state transition.

Capture

Captured from the work item's 'Created Date' field.

Event type explicit
Build Succeeded
This activity confirms that the source code, including the new changes, has been successfully compiled and packaged by a build pipeline. This is an explicit event logged by Azure Pipelines.
Why it matters

Serves as a critical quality gate, ensuring that new code integrates correctly without breaking the build. Failures at this stage can indicate integration issues.

Where to get

Captured from Azure Pipelines build completion events. The build needs to be linked to the work item, either directly or through the associated pull request.

Capture

Captured from Azure Pipelines build completion event.

Event type explicit
Development Completed
Signifies that all development and unit testing activities are complete, and the item is ready for formal testing. This is typically inferred from a work item state change to 'Resolved' or 'Ready for Test'.
Why it matters

This marks a major handoff from the development team to the QA team. Measuring the time until 'QA Testing Started' helps identify handoff delays.

Where to get

Inferred from the work item history when the System.State field changes to a value like 'Resolved' or a custom state indicating readiness for QA.

Capture

Inferred from State field changing to 'Resolved'.

Event type inferred
QA Testing Completed
Marks the successful completion of the quality assurance phase. This is inferred when the work item state changes from a testing state to one like 'Ready for UAT' or 'QA Approved'.
Why it matters

This is a key quality gate indicating the item is ready for user acceptance testing or release. Delays after this point may indicate UAT or release planning bottlenecks.

Where to get

Inferred from the work item history when the System.State field changes from 'In QA' to a subsequent state like 'Ready for UAT' or 'Done'.

Capture

Inferred from State field changing from 'In QA' to 'Ready for UAT'.

Event type inferred
QA Testing Failed
Indicates that the work item has failed quality assurance testing and is being sent back to development. This is captured by a state change from a testing state back to an 'In Progress' or 'Active' state.
Why it matters

This activity is essential for identifying rework loops. A high frequency of this event points to issues with code quality, requirements, or testing processes.

Where to get

Inferred from the work item history by detecting a transition from a state like 'In QA' back to a state like 'Active' or 'In Progress'.

Capture

Inferred from State field changing from 'In QA' back to 'Active'.

Event type inferred
UAT Started
Represents the beginning of User Acceptance Testing, where business stakeholders validate the functionality. This is typically inferred from a state change to 'In UAT' or a similar status.
Why it matters

Measures the start of the final validation before release. The duration of UAT and wait times for approval are critical to analyze for process optimization.

Where to get

Inferred from the work item history when the System.State field is updated to a custom state representing UAT, such as 'In UAT'.

Capture

Inferred from State field changing to 'In UAT'.

Event type inferred
Work Item Approved
Represents the formal approval of a work item, confirming it is well-defined and ready for development. This is typically inferred from a change in the 'State' field to a value like 'Approved' or 'Ready for Dev'.
Why it matters

Tracking approvals helps analyze the time between idea submission and development commitment. It highlights potential delays in the planning and backlog grooming phases.

Where to get

Inferred from the work item history by detecting a change of the System.State field to 'Approved' or a similar custom state.

Capture

Inferred from State field changing to 'Approved'.

Event type inferred
Work Item Cancelled
Indicates that the work item has been cancelled and will not be completed or deployed. This is captured by a state change to 'Removed', 'Cancelled', or a similar state.
Why it matters

This represents an alternative, unsuccessful process ending. Analyzing cancelled items can reveal issues with planning, prioritization, or requirement definition.

Where to get

Inferred from the work item history when the System.State field is changed to a terminal state in the 'Removed' category.

Capture

Inferred from State field changing to 'Removed' or 'Cancelled'.

Event type inferred
Work Item Closed
Represents the final closure of the work item after deployment and any post-deployment validation. It is captured by a state change to 'Closed' or 'Done'.
Why it matters

This activity marks the final, successful completion of the entire process for a work item. It is the definitive end point of the lifecycle.

Where to get

Inferred from the work item history when the System.State field is changed to 'Closed' or a similar terminal state in the 'Completed' category.

Capture

Inferred from State field changing to 'Closed'.

Event type inferred
Recommended Optional

Extraction Guides

How to get your data from Azure DevOps