Your Software Development Lifecycle Data Template
Your Software Development Lifecycle Data Template
- Recommended attributes to collect
- Key activities to track for your SDLC
- Detailed extraction guidance for Azure DevOps
Software Development Lifecycle Attributes
| 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
|
|||
Software Development Lifecycle Activities
| 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
|
|||