Feature Requests

As a user of the SEI platform, I want the search bar to provide AI-powered suggestions for selecting and configuring widgets, so that I can easily find the right widgets for my use case without needing extensive knowledge of the platform or its configurations. Acceptance Criteria: AI-Driven Widget Suggestions: When a user inputs a query describing their use case (e.g., "I want to see developer velocity"), the system suggests relevant widgets (e.g., "Coding Days", "Velocity Report"). Instructional Guidance: Along with widget suggestions, the system provides step-by-step instructions for configuring the widget, such as: Selecting the appropriate metrics (e.g., "Sum of Story Points"). Choosing the correct aggregation (e.g., "Sprint" or "Team"). Natural Language Processing (NLP): The search bar interprets natural language queries effectively and maps them to relevant widgets and configurations. Coverage of Common Use Cases: The AI supports common use cases, such as: "I want to see sprint-by-sprint progress" → Suggest "Issues Report" with instructions for configuring Story Points and Sprint aggregation. "I want to track developer productivity" → Suggest "Coding Days", "Pull Requests Completed", etc. "Show me cycle time trends" → Suggest "Cycle Time Trend" and relevant configurations. Error Handling: If no relevant widgets are found, the system provides helpful alternatives or suggestions to refine the query. Customization Options: Users can provide feedback on the suggestions to refine the AI's results over time (e.g., marking a widget as relevant or irrelevant). Integration with Existing Widgets: The feature integrates seamlessly with the platform’s widget library and dynamically updates based on available widgets. Benefits: Reduces friction for users unfamiliar with the platform. Improves adoption and utilization of widgets. Enhances overall user experience by simplifying the widget selection process.

As a user of SEI Insights, I want the ability to schedule reports and receive email notifications for insights, So that I can automatically stay updated on key metrics and trends without manually accessing the platform. Acceptance Criteria: Scheduled Reports: Users can schedule reports for any insight or dashboard. Scheduling options should include: Frequency: Daily, Weekly, Monthly, or Custom intervals. Time: Specific time of day to send the report. Reports should be delivered as downloadable attachments (e.g., PDF or Excel) or via an embedded link in the email. Email Notifications: Users can opt-in to receive email notifications for insights or dashboards. Emails should include: A summary of key metrics/trends. A link to the detailed insights/dashboard in SEI. Any visual elements like charts/graphs (optional but preferred for improved clarity). Configuration Options: Users with appropriate permissions should be able to: Select specific insights/dashboards to include in the report. Customize recipients (individuals or groups). Set report format (PDF, Excel, etc.). Access Control: Email notifications and scheduled reports should respect user permissions. Users without access to an insight or dashboard should not receive reports for that content. Report History: A log of all scheduled reports sent should be accessible within the platform (e.g., under "Reports History"). Error Handling: If a report generation fails, the system should notify the user via email with an error message and a retry option.

As a user of SEI widgets, I want the ability to add annotations (e.g., notes, markers) to widgets to indicate significant events like releases or changes, So that I can track the impact of those events (positive or negative) on the widget metrics over time. Acceptance Criteria: Annotation Capability: Users should be able to add annotations to widgets by specifying: Title (e.g., "Release 1.2.3 Deployed") Date/Time (e.g., December 16, 2024) Optional Notes (e.g., "Release focused on bug fixes and performance improvements"). Annotation Display: Annotations should appear on the widget as: A marker (e.g., vertical line, dot, or pin) on charts that have a time axis. Hover-over or inline text with annotation details when the marker is interacted with. Annotation Persistence: Annotations must persist across user sessions and be visible to all users who have access to the widget. Users should have the ability to edit or delete annotations if they have sufficient permissions. Non-Editable Access for Viewers: Users without edit permissions can only view annotations and not modify or add them. Annotation Management: Users should be able to: Add new annotations. Edit existing annotations. Delete annotations. Include a history/log of all annotations made on a widget. Impact on Metrics: Annotations are for context only and should not modify the widget's data or functionality. User Experience: Annotations must integrate seamlessly with the widget UI. Ensure clear visual representation and minimal clutter, even if multiple annotations exist.

As a user or viewer of SEI widgets, I want the ability to see the defined settings (e.g., Small, Medium, Large thresholds) as a legend directly on the widget UI, And have an option to quickly change the values directly from the widget without needing edit access, So that I can perform quick analysis and adjustments without navigating through multiple steps like Edit > Settings. Acceptance Criteria: Settings Visibility: Display the “Options” settings (e.g., thresholds for Small, Medium, Large) as a legend on the widget UI itself. The legend should be visible to all users, regardless of edit permissions. Quick Edit Capability: Allow users with appropriate permissions to quickly edit the thresholds (e.g., change Small from 50 to 40 lines of code) directly on the widget UI. Users should see the updated metrics on the widget immediately after making changes. Non-Editable Access for Viewers: For users without edit access, the settings/thresholds should still be visible as a legend, but editing capability should be disabled. Dynamic Update of Metrics: When threshold values are changed, the widget metrics (e.g., PR Code Change Size chart) should dynamically update to reflect the new values without requiring a page reload. User Experience: Changes to thresholds should be intuitive (e.g., inline editing or a simple modal on click). Ensure smooth interaction and avoid disruption to existing workflows. Error Handling: If a user inputs an invalid value, display an appropriate error message and do not save the changes. Note: PR Code Change Size is an example widget I sued, but the user wants this for all widgets Who are "they"? The users for this feature primarily include: L1 Managers and Team Leads: They need to monitor key metrics and thresholds (e.g., PR size, code churn) to identify trends, anomalies, or areas needing attention quickly. Developers: While not primary decision-makers, developers may also want visibility into these thresholds to understand how their work is being measured and tracked. Senior Leadership (Secondary): Leadership may occasionally view widgets for broader insights but are not likely to edit the thresholds themselves. What is this for? The feature serves two purposes: Transparency of Widget Metrics: Users can view the defined thresholds (e.g., Small, Medium, Large PR size) directly on the widget UI as a legend. This improves visibility into how metrics are being evaluated, ensuring alignment and clarity on what constitutes "small," "medium," or "large" contributions. Quick Adjustments for Contextual Insights: Users with permissions can edit thresholds directly from the widget UI without navigating through multiple steps (e.g., Edit > Settings). This saves time and allows teams to perform quick experimentation and adjustments to thresholds based on their team’s unique context or evolving needs. What do they get out of it? Improved Efficiency: Eliminates the friction of navigating multiple steps to view or adjust thresholds, streamlining workflows. Better Context for Decision-Making: Quick edits allow users to explore "what-if" scenarios, helping them adapt metrics to their evolving goals. For example: Adjusting PR size thresholds to better reflect team productivity or code review efficiency. Transparency and Alignment: View-only users (e.g., developers or stakeholders) gain a clear understanding of how thresholds impact the insights they see, fostering alignment across teams.

As a user of SEI Insights, I want the ability to select individual Jira projects from a project dropdown, So that I can easily and directly view insights specific to the projects (or repos) I care about, without needing to create or manage collections. Acceptance Criteria: Jira Project or SM Repo Dropdown Availability: A dropdown menu should display all Jira projects or SCM repos associated with the connected Jira instance or SCM Repos. The dropdown should dynamically fetch and display project names with no manual setup required by users. Project Selection Behavior: Users should be able to select one or multiple projects or repos from the dropdown. Selected projects or repos should directly drive the insights displayed on the page. Impact on Insights: Metrics and insights should refresh dynamically to reflect the data from the selected projects or repos, similar to how collections drive insights today. Fallback to Collections: If a user prefers to use collections, the option to select collections should still remain available. Error Handling: If the user doesn’t have access to a specific project, the dropdown should either: Exclude those projects, or Display an appropriate access error message. Who are the users? The primary users for this feature would likely be L1 managers, team leads, or senior leadership who are actively tracking project-level metrics and insights. L1 Managers/Team Leads: These users often need to quickly drill down into specific projects or repositories to monitor team performance, identify issues, and take corrective actions. Senior Leadership: While they may not use this feature on a day-to-day basis, senior leaders may still benefit from high-level comparisons across projects to understand broader trends and overall team efficiency. Why do they want to do this? The intent goes beyond just a UI visual change; it addresses a functional need: Ease of Use & Efficiency: Selecting specific projects directly from a dropdown simplifies the workflow. It avoids the complexity of creating and managing collections, which can be time-consuming for users who only want to focus on a specific project or two. Identifying Bottlenecks or Trends: Users want to drill into individual Jira projects or repositories to identify bottlenecks (e.g., PR cycle time, deployment delays, etc.) or focus on areas needing improvement. It enables project-specific insights, which helps in decision-making and driving performance improvements. Flexibility: While collections work for broader views, users need the flexibility to quickly switch focus to a specific project and immediately see relevant insights without additional configuration.

who is the persona Quality engineering What can’t be achieved if the said ask is not there Will not be able to quickly aggregate the metrics displayed What are the alternatives they are using Pulling the metrics and using other tools to generate the graphs What’s the big deal if the said ask is never going to be supported. Lot of manual work for the teams to generate the graphs

Widget to track status of epics and analyze work done, pending, distribution and estimation.

Today if a ticket moves from status A (occurrence 1)-> B -> C -> A (occurrence 2) the lead time calculates for status A from occurrence 1 and we want that to be calculated from the recent status A time which is occurrence 2.

We have nested collections, there are three levels. It would be great if a parent collection could inherit the mappings of its children's collection. Currently, we have to map a GitHub repo at three places.

Hi team, We have a couple of products using custom fields with time values, however, the tool currently is not able to track dynamically these custom fields. Examples of these are: Ability to read custom stages; ability to read a custom due date for hygiene reports; ...