Feature Requests

Problem “Work Completed per Developer” drilldown shows developers associated with tickets but displays ticket resolution time as the effort metric. Resolution time reflects ticket lifecycle duration — not actual developer effort. Since SEI tracks active work statuses and contributor activity, effort duration per developer is available but not surfaced. Feature Request Display developer effort duration alongside overall ticket resolution time in productivity drilldowns. Proposed Capability For each developer on a ticket: Show: Active work duration (time in active statuses attributed to that developer) Overall ticket resolution time Provide toggle: View by effort time View by lifecycle duration Clearly differentiate: Individual effort contribution Total ticket cycle time Expected Outcome Accurate representation of developer contribution. Reduced misinterpretation of productivity. Stronger credibility in performance analytics. Enables fair workload and effort distribution analysis.

Problem MTTR assumes incidents are managed within the same Jira project as delivery work. Many organizations manage incidents in separate projects (e.g., centralized incident management). This results in incomplete MTTR measurement. Feature Request Allow metric-level filter override for MTTR to support cross-project incident sourcing. Proposed Capability Enable selection of a different Jira project (or multiple projects) for incident-type tickets. Allow override of default team/project filters specifically for MTTR. Support filtering by: Issue type (Incident, Sev1, Sev2, etc.) Custom fields Labels Allow mapping of delivery project with incident project. Expected Outcome Accurate MTTR in organizations with centralized incident management. Elimination of project-structure dependency. Proper DORA compliance for enterprise setups.

CFR today tracks failed pipeline executions vs successful executions. This underrepresents real production failures, which may include: Rollbacks Hotfix deployments Deployments linked to incidents The goal is to expand failure identification criteria for Change Failure Rate beyond pipeline failure status. We propose SEI to allow Admins to define production failure using configurable criteria such as: Rollback deployment detected Deployment tagged with incident ID Incident created within X hours of deployment Custom tag/label indicating failed release Linked Jira incident ticket Support logical rules: AND/OR combinations Time-window association between deployment and incident Expected Outcome More accurate DORA-aligned CFR. Ability to align measurement with organizational definition of production failure. Better auditability of what qualifies as a failed change.

Lead Time currently measures all tickets that meet the base filter criteria. Teams cannot explicitly include or exclude specific ticket types, workflows, or labels that should (or should not) contribute to Lead Time. This reduces metric fidelity and makes the signal noisy. The ask for this request is to enable configurable inclusion/exclusion filters for tickets contributing to Lead Time.

Today CFR is driven by IM. Moniepoint uses PagerDuty for the source of truth for CFR

We support our internal teams in takeda to create SEI collections. I am wondering why for already delivered SEI collection and Collection admin , we do not provide more autonomy in regards of adding/removing people to and from given SEI collection. That concept of self organization / delegation is very efficient. We receive lots of requests "please add me to this or that collection" and that is painful to manage centrally.

Provide more information in the audit log, such as what areas were changed. This will help better track collection configurations and insights.

Today in SEI, the efficiency dashboard only provides a summary and not a list of individual tickets. In SEI 1.0, this is available The purpose of having this is to understand whether there is data gaps between 1.0 and 2.0 or with internal systems.

In SEI 2.0, we would like to see the available JIRA statuses, not just the hardcoded ones. The problem with hardcoded statuses is that we do not have any data for 'Planning' phases because the required status is not available. Otherwise, the data does not align to customer internal data.