Improving Classification And Allocation For Multiple Team Members Via Subtasks And Git History

Introduction

In agile project management, accurate time allocation is crucial for understanding team workload, project progress, and resource utilization. Classification and allocation are key components of this process. This article addresses the challenge of improving time allocation accuracy when multiple team members contribute to a single story through subtasks or direct commits. We delve into the current limitations of excluding Jira subtasks and the necessity of incorporating Git history to ensure comprehensive contributor recognition. The goal is to enhance the classification + allocation logic to automatically detect all contributors, proportionally split time, and reflect this breakdown in final outputs, ultimately leading to more efficient and transparent project management.

Current Challenges in Time Allocation

Currently, the sprint allocation logic simplifies calculations by excluding Jira subtasks from the final time allocation. While this approach streamlines the process, it hides important effort data when multiple team members contribute via subtasks linked to a single parent story. This exclusion leads to an incomplete picture of team effort and can result in inaccurate workload assessments. When calculating the allocation percentage, the system focuses solely on the parent story, requiring manual intervention to account for contributions made through subtasks. This manual process involves several steps:

• Checking which team members worked on related subtasks.
• Adding up their time or story points.
• Including them in the time distribution.
• Manually inspecting the Git history to see who committed code related to the main story when no subtasks exist.

This manual effort is inefficient and error-prone. It not only consumes valuable time but also increases the risk of overlooking contributors, leading to an uneven distribution of credit and potential inaccuracies in project reporting. The lack of automation in this area highlights a significant gap in the current system, necessitating a more comprehensive and integrated approach to time allocation.

Objective: Enhancing Classification and Allocation Logic

The primary objective is to enhance the classification + allocation logic to provide a more accurate and comprehensive view of team contributions. This enhancement will ensure that all team members who contribute to a story, whether through subtasks or direct commits, are properly recognized and accounted for in the time allocation process. The improved system should automatically roll up subtasks’ participants and effort into the parent story, ensuring that no contributions are overlooked. This includes identifying and counting all engineers who worked on subtasks as contributors to the main story, providing a holistic view of the effort involved.

To achieve this, the system will need to incorporate Git history analysis. In cases where there are no subtasks, the system should check Git history for commits matching the story branch, commit messages, or pull requests. This integration will ensure that contributions made directly through code commits are also captured and attributed to the appropriate team members. The ultimate goal is to create a TimeAllocation output that includes all contributors with proportional splits, reflecting the true distribution of effort across the team. This enhanced system will improve the accuracy of sprint allocations and provide a clearer understanding of team contributions.

Acceptance Criteria: Ensuring Comprehensive Contributor Recognition

To ensure the enhanced classification and allocation logic meets the project's objectives, several acceptance criteria have been defined. These criteria outline the specific functionalities and outcomes that must be achieved to consider the implementation successful. When running sprint allocation, the logic must automatically detect linked subtasks for each parent story, gather all assignees from those subtasks, and include them in the total TimeAllocation for that parent story. This ensures that all contributions made through subtasks are properly accounted for and integrated into the overall time allocation.

In cases where there are no subtasks, the tool should look up the Git history for commits referencing the story key (e.g., FN-123), resolve contributor Git usernames, and map them to known users in the system. This Git history integration is crucial for capturing contributions made directly through code commits. The total time percentage should be split proportionally among contributors, with options for either an even split by default (e.g., 2 people → 50% each) or weighting by subtask points if available. The final TimeAllocation output must list all contributors per story and sum to 100% when combined, providing a clear and comprehensive view of effort distribution. Additionally, the updated CSV must include a column for each contributor with their share, and the Jira push must log the time against each participant properly (if supported).

To validate the functionality, tests will be added to cover various scenarios, including a parent story with multiple subtasks (ensuring all contributors are counted), a parent story with no subtasks (ensuring Git contributors are found), and edge cases such as unknown commit authors (ensuring a clean fallback). Meeting these acceptance criteria will guarantee that the enhanced system accurately captures and allocates time for all contributors, improving the overall efficiency and transparency of sprint allocations.

Implementation Notes: Structuring the Solution

Implementing the enhanced classification and allocation logic requires careful consideration of the system's architecture and data structures. To support multiple contributors per story, the Sprint and TimeAllocation structs should be extended to support []Contributor instead of a single user. This change will allow the system to accurately track and manage contributions from multiple team members on a single task. A GitClient helper should be added to handle Git history analysis. This helper will use git log --grep or similar commands to find commits by story ID and map commit authors to configured user IDs. The GitClient will be instrumental in identifying contributors who have made direct code commits related to a story.

An option to skip the Git check (--skip-git) should be added for situations where Git history analysis is not required or desired. Configuration should be used to handle Git-to-Jira user mappings if usernames differ, ensuring accurate attribution of contributions across systems. It is crucial to ensure that subtasks are still excluded from double-counting points; only their people/effort should roll up to the parent story. This prevents inflation of story points and maintains the integrity of sprint planning metrics. By following these implementation notes, the enhanced system will be robust, flexible, and accurate in capturing and allocating time across multiple contributors.

Testing: Ensuring Accuracy and Reliability

Comprehensive testing is essential to validate the accuracy and reliability of the enhanced classification and allocation logic. Unit tests should be developed for subtasks → parent rollup, ensuring that contributions from subtasks are correctly aggregated to the parent story. Unit tests should also be created for Git contributor detection, verifying the system's ability to accurately identify contributors based on Git history. An integration test should be performed on a full sprint with stories, subtasks, and Git data to confirm that the final allocation includes everyone, providing end-to-end validation of the system's functionality.

This integration test will simulate real-world scenarios, ensuring that all components of the system work seamlessly together. It is also crucial to ensure that the CSV and Jira push reflect the multi-contributor split accurately, maintaining data consistency across platforms. By conducting thorough testing, potential issues can be identified and resolved early, ensuring that the enhanced classification and allocation logic performs as expected in a production environment. This rigorous testing approach will build confidence in the system's accuracy and reliability, leading to more informed decision-making and improved project management outcomes.

Conclusion

Enhancing the classification and allocation logic to handle multiple team members via subtasks and Git history is a crucial step towards more accurate and transparent project management. By addressing the limitations of the current system and implementing the proposed enhancements, organizations can gain a clearer understanding of team contributions, leading to improved resource allocation, workload management, and project reporting. The incorporation of subtask contributions and Git history analysis ensures that all team members are properly recognized for their efforts, fostering a more equitable and efficient working environment. Thorough testing and careful implementation will be key to realizing the full benefits of this enhanced system.