Enterprise Apps: current Issue Weights
Purpose of this issue
In this issue, Project Leads will document the current current Issue Weights of the Enterprise Apps team.
Overview of the current Enterprise Apps Issue Weights
Issue Weights
Issue weight is an estimate of how much time is required to complete the tasks in the issue. The idea is to go over the problem statement raised in the issue with the team that will be working on it and put it into one of 5 buckets: XS, S, M, L, XL as a way to group the unit of work.
Process
- When an issue is opened for the Enterprise App team with the appropriate labels, a team member must be assigned.
- The assignee works with all parties involved in the issue to recommend a weight.
- After the issue is closed, the assignee who helped coordinating the the work can update the weight to reflect the actual effort if different from the original weight. They should provide a reason and mention it in the Enterprise Applications Sync or in the Enterprise Applications wiki to help us improve our weighting accuracy going forward.
Guidelines
| Size/Weight | Description | Estimate work range |
|---|---|---|
| XS:1 | A task. Example: - Documentation update. |
<4 hours |
| S:2 | The problem statement has been determined and a solution identified. No need for (extra) discussion with other teams or people. Examples are: - A problem that has been discussed but needs an issue to track the development and outcome. - Regular bugs to be addressed by the Integrations engineers where some investigation has already taken |
4 hours / half a day |
| M:3 | The problem statement has been defined with understood requirements. A solution is yet to be identified and coordination with other teams or people may be required. Bugs that are not fully understood and may not yet have a suggested solution. Extra investigation is required but the expectation is that once a solution is identified, it should be relatively easy to implement. Examples are: - A deliverable from an ongoing project that will involve different teams and coordination from a BSA (Business Systems Analyst) to help find and implement a solution. - Most system bugs or performance issues. |
8 hours / 1 day |
| L:5 | The problem statement has been defined but a solution will require extra investigation in order to be identified and implemented. Surprises are expected, different teams will have to be involved and a BSA (Business Systems Analyst) assistance is needed. Bugs that are very poorly understood and will not have a suggested solution. Significant investigation will be required and once the problem is found, a solution may not be straightforward. Examples are: - A deliverable from an ongoing project that will involve different teams and coordination from a BSA (Business Systems Analyst) to help find and implement a solution. Bugs or system workflows that negatively impact the work of other people. |
12 hours / 1.5 days |
| XL:8 | The problem statement has been defined but it's a significant change that has dependencies and the requirements are probably not fully understood or known. It's unlikely we would resolve this in just one issue and the preference would be to further clarify requirements and/or break into smaller issues. Example: - A new system or module implementation. |
16 hours / 2 days |
Next Steps
- @broncato to link with EntApps DRIs to gather use cases for better understanding of tasks.