Jira MCP Toolset

# Continuity Analysis Implementation ## Purpose The Continuity Analysis examines how consistently and efficiently work progressed on a Jira issue. This analysis identifies patterns of stagnation, communication gaps, context switching, and work fragmentation that may have impacted the issue's overall flow and efficiency. ## Function Signature ```typescript function getContinuityAnalysis(issue: JiraIssue, commentsResponse: IssueCommentResponse): IssueAnalysisResult['continuity'] ``` ## Implementation Approach ### Flow Efficiency Calculation 1. Calculate the total elapsed time from issue creation to completion (or current date if not complete) 2. Calculate the active work time by: - Identifying periods where the issue was in active status (not blocked or waiting) - Summing up these active time periods 3. Calculate flow efficiency as: (active work time / total elapsed time) * 100 ```typescript // Simplified concept const totalElapsedTime = completionDate - creationDate; const activeWorkTime = calculateActiveWorkPeriods(issue); const flowEfficiency = (activeWorkTime / totalElapsedTime) * 100; ``` ### Stagnation Periods Identification 1. Analyze the issue's changelog to identify periods with no updates 2. Define a threshold for stagnation (e.g., 3 business days without updates) 3. For each stagnation period, record: - Start and end dates - Duration in business days - Status during stagnation - Assignee during stagnation 4. Calculate the longest stagnation period ```typescript // Simplified concept const stagnationThresholdDays = 3; // Business days const stagnationPeriods = findPeriodsWithoutUpdates(issue, stagnationThresholdDays); const longestStagnationPeriod = Math.max(...stagnationPeriods.map(p => p.durationDays)); ``` ### Communication Gaps Analysis 1. Analyze the comment timestamps to identify periods without communication 2. Define a threshold for communication gaps (e.g., 5 business days without comments) 3. For each gap, record start date, end date, and duration 4. Exclude periods where active work was happening without need for communication ```typescript // Simplified concept const communicationThresholdDays = 5; // Business days const communicationGaps = findPeriodsWithoutComments(commentsResponse, communicationThresholdDays); ``` ### Context Switching Impact Analysis 1. Analyze the changelog for assignee changes 2. For each assignee change, record: - Date of change - Previous and new assignee - Issue status at time of change - Days from issue start 3. Calculate total number of context switches 4. Assess velocity impact by comparing work pace before and after handoffs ```typescript // Simplified concept const assigneeChanges = extractAssigneeChangesFromChangelog(issue); const contextSwitches = { count: assigneeChanges.length, timing: assigneeChanges.map(change => ({ date: change.date, fromAssignee: change.from, toAssignee: change.to, status: getStatusAtTime(issue, change.date), daysFromStart: calculateBusinessDays(issue.fields.created, change.date) })), impact: assessVelocityChangeAfterHandoffs(issue, assigneeChanges) }; ``` ### Momentum Indicators Analysis 1. Calculate comment frequency and consistency 2. Analyze update patterns throughout the lifecycle 3. Assign a momentum score (1-10) based on these factors: - Regular updates and consistent progress - Minimal stagnation periods - Prompt responses to questions - Consistent velocity ```typescript // Simplified concept const commentFrequency = calculateCommentFrequency(commentsResponse); const updateConsistency = calculateUpdateConsistency(issue); const momentumScore = calculateMomentumScore(commentFrequency, updateConsistency, stagnationPeriods); ``` ### Work Fragmentation Analysis 1. Identify distinct active work periods by looking at status changes and updates 2. Calculate a fragmentation score (1-10) where: - 1 = Highly fragmented (many small, disconnected work periods) - 10 = Continuous work (few, long uninterrupted work periods) 3. Count the number of distinct active work periods ```typescript // Simplified concept const activeWorkPeriods = identifyActiveWorkPeriods(issue); const fragmentationScore = calculateFragmentationScore(activeWorkPeriods); ``` ### Late-Stage Changes Identification 1. Define "late-stage" as after a certain percentage of the issue's lifecycle (e.g., >70%) 2. Analyze changelog for significant field changes during late stages: - Description changes - Scope changes (story points, effort) - Acceptance criteria changes 3. For each late change, record the date, affected field, description, and completion percentage ```typescript // Simplified concept const lateStageThreshold = 0.7; // 70% complete const lateStageChanges = findLateStageChanges(issue, lateStageThreshold); ``` ### Feedback Response Time Calculation 1. Analyze comments to identify question-response pairs 2. Calculate the average time between questions and their responses 3. Only count business hours (exclude weekends/nights) ```typescript // Simplified concept const questionResponsePairs = identifyQuestionResponsePairs(commentsResponse); const feedbackResponseTime = calculateAverageResponseTime(questionResponsePairs); ``` ## Integration with Main Analysis Function To integrate this into the existing `analyzeIssue.ts` file: ```typescript import { getContinuityAnalysis } from './continuityAnalysis/getContinuityAnalysis'; export function analyzeIssue(issue: JiraIssue, commentsResponse: IssueCommentResponse): Partial<IssueAnalysisResult> { // Existing code... const continuityAnalysis = getContinuityAnalysis(issue, commentsResponse); return { // Existing fields... continuity: continuityAnalysis, }; } ``` ## Helper Functions Several helper functions will be needed for this analysis: 1. `calculateBusinessDays(startDate, endDate)`: Calculate business days between dates 2. `isActiveStatus(status)`: Determine if a status represents active work 3. `findPeriodsWithoutUpdates(issue, thresholdDays)`: Identify stagnation periods 4. `extractAssigneeChangesFromChangelog(issue)`: Get assignee change history 5. `identifyQuestionResponsePairs(comments)`: Find question-answer pairs in comments 6. `calculateCompletionPercentage(issue, date)`: Estimate completion percentage at a given date ## Considerations for Implementation 1. **Performance**: Some calculations might be computationally intensive for issues with extensive histories. 2. **Accuracy**: Business days calculations should account for holidays and organization work schedules. 3. **Heuristics**: Question-answer identification and momentum scoring require heuristic approaches. 4. **Thresholds**: Stagnation and communication gap thresholds might need to be configurable. 5. **Status Mapping**: Different Jira instances have different workflows and status names, so status categorization logic should be flexible. ## Testing Approach 1. **Unit Testing**: - Test each helper function with various input scenarios - Use mock issue data with controlled changelog entries - Test edge cases (zero comments, single assignee, etc.) 2. **Integration Testing**: - Test the full `getContinuityAnalysis` function with realistic issue data - Verify all fields of the returned object match expected format 3. **Regression Testing**: - Ensure changes don't break existing analysis components - Validate against a set of reference issues with known characteristics