You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While GitHub is the primary tool used by the Data Operations team for code development and task tracking, we sometimes use Azure DevOps instead for clients that are already established in the Azure environment. This page covers practices and guidelines to be followed when using DevOps from a project management perspective to ensure work items contain sufficient detail so we know what needs to be done, how much effort is involved, and how to prioritize it against other issues.
1. Epics are used to group work under larger categories, for example "Phase 1 Data Source Modeling".
9
+
1. All work should roll up to an Epic. These can be broad categories like "Phase 1 Data Modeling", for example.
10
+
2. Issues and tasks are used to track work.
11
+
1. Issues will be our primary work item type.
12
+
2. Tasks to break the work out further as needed. These are the detailed steps needed to complete the issue. Tasks can also be used to assign work that is split between multiple people, since DevOps only allows for one assignee on a work item.
1. Title: This can be short, but should give enough detail to identify what work this issue is related to and differentiate it from similar task. For example, “Review Documentation for [Specific Data Source Name]”, as opposed to “Review Documentation” which is too vague.
21
+
2. Description: This should be detailed enough that anyone viewing the issue knows what work needs to be done, and what the ideal outcome or deliverable is once this work is complete (success criteria).
22
+
3. The following items should always be filled in when creating a new issue. If you are unsure what to enter, reach out to the Project Manager to discuss, or bring it up in daily standup or weekly sprint planning meetings to discuss with the team.
23
+
1. Assignee: If you are unsure who to assign the item to, leave it blank for now. Then add a comment that you think it may need to be assigned to someone else and we can discuss in the next team meeting. Note that unliked GitHub, Azure DevOps only allows assigning a work item to a single person. To assign something to multiple people it must be broken out into multiple work items.
24
+
2. Priority: Indicates how soon the work needs to start. See definitions in the appendix at the end of this document.
25
+
3. Effort: Effort indicates how much time the work will take to complete once it has started. See definitions in the appendix at the end of this document. Tasks should ideally be sized appropriately so that they can be completed in <1 sprint of work. So Tiny (1 hour), Small (1 day), and Medium (1 week) are appropriate sizes for tasks. A Large (2+ weeks) or X-Large (months) task should be broken up into smaller work items for easier tracking from sprint to sprint.
26
+
4. Iteration (aka Sprint): We track work in two-week sprint cycles. Sprint names follow the a convention of [current year]-[sequential sprint number]. So the first sprint of the year 2025 is "2025-01". The last sprint of the year 2025 is "2025-26".
27
+
1. If work on an issue or task will start within the next 2 sprints, assign it to the appropriate sprint during Sprint Planning meetings. Work planned further than 2 sprints out does not need to be assigned to a sprint and can be left in the backlog, unless there is a known due date or we want to make sure something starts at a certain date.
28
+
5. Area: This is a high level category at a broader level than Epic. Examples are Data Modeling, Training, Data Onboarding, etc. This is used for tracking purposes only. The Project Manager can help assign to the correct Area if needed.
29
+
7. Status: Assign a status on the current state of the issue. See below for status options. Make sure to fully close a work item when completed by setting the status to Done.
30
+
31
+
32
+
## Effort Definitions
33
+
34
+
Note: Effort is a numeric open text box in Azure DevOps, rather than a drop-down with predetermined options like in GitHub. Below we list the numeric value to enter for the different Effort levels, in order to standardize across our projects. The sizes we use are roughly equivalent to the number of days we think the work will take to complete. We use 0.125 for Tiny as it aligns with one hour in a 8-hour work day.
35
+
36
+
**Tiny = 0.125**
37
+
38
+
- Easy task, something that can be completed in about an hour. It may not require issue creation but could use as a reminder to complete the task later in the sprint (if something takes less than 30 minutes, no need for an issue).
39
+
- Example: Sending a follow-up email
40
+
41
+
**Small = 1**
42
+
43
+
- A task that can be completed in one day
44
+
- Example: Reviewing documentation on an API to determine how to onboard a new data source.
45
+
46
+
**Medium = 5**
47
+
48
+
- A task that can be completed in about a week
49
+
- More complex but still straightforward to complete
50
+
- Example: Creating a staging or intermediate data model for a source that is well-understood and does not require complex logic.
51
+
52
+
**Large = 10**
53
+
54
+
- A task that can be completed in 2 or more weeks
55
+
- Increased complexity, may require slower manual work or unknowns that require research and discovery
56
+
- Example: Writing an API script for a new, unknown data source.
57
+
58
+
**X-Large = 20**
59
+
60
+
- Tasks that may take a month or longer to complete
61
+
- Consider breaking up into smaller work items if possible
62
+
- Example: Building a full set of end-to-end models for a new data source, including staging, intermediate, and mart models.
63
+
64
+
## Priority Definitions
65
+
66
+
Note: Priority in Azure DevOps is a dropdown with options from 1-4. We use the following definitions for those numbers to standardize across our projects.
67
+
68
+
**Urgent = 1**
69
+
70
+
- Top priority, usually reserved for unexpected emergency item.
71
+
- Putting everything else on backburner, aiming for completion ASAP
72
+
- Not assigned as part of regular sprint planning process
73
+
74
+
**High = 2**
75
+
76
+
- Goal is to complete this sprint
77
+
78
+
**Medium = 3**
79
+
80
+
- Less important than High, aim to complete within 2-4 sprints
81
+
- OK to push to next sprint if needed
82
+
83
+
**Low = 4**
84
+
85
+
- Work on as time allows, may leave in backlog
86
+
87
+
## Status Definitions
88
+
89
+
1.**To Do**: This is the default status when a work item is created, indicates no work has started yet.
90
+
2.**Doing**: Choose this status once work has started on the issue.
91
+
3.**Done**: Indicates the work item is completed. If the work item is linked to a Pull Request, you will be given an option to close it when merging the PR. Or you can choose this status when viewing the work item.
Copy file name to clipboardExpand all lines: docs/code/github-project-management.md
+18-18Lines changed: 18 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -16,72 +16,72 @@ These guidelines are meant to ensure that issues are created in a standardized f
16
16
3. The following items should always be filled in when creating a new issue. If you are unsure what to enter, reach out to the Project Manager to discuss, or bring it up in daily standup or weekly sprint planning meetings to discuss with the team.
17
17
1. Assignee: If you are unsure who to assign the item to, assign it to yourself to avoid losing track of the issue. Then add a comment that you think it may need to be assigned to someone else and we can discuss in the next team meeting.
18
18
2. Priority: Indicates how soon the work needs to start. See definitions in the appendix at the end of this document.
19
-
3. Size: Size indicates how much time the work will take to complete oncgite it has started. See definitions in the appendix at the end of this document.
20
-
4. Sprint: If the work will start within the next 6 weeks, assign it either to the current or next 2-3 sprints. Work planned further than 3 sprints out does not need to be assigned to a sprint. In this case set the status to “Backlog” and assign a Due Date. If there is not a known due date for the work, this should be a date by which the work needs to be added to a sprint so it does not get lost.
21
-
5. Project: This field is important because it ensures the issue is surfaced in the correct location. If you are unsure of the project, the Project Manager can help identify the correct selection.
19
+
3. Size: Indicates how much time the work will take to complete once it has started. See definitions in the appendix at the end of this document.
20
+
4. Sprint: We track work using two-week sprint cycles. Sprint names follow the a convention of [current year]-[sequential sprint number]. So the first sprint of the year 2025 is "2025-01". The last sprint of the year 2025 is "2025-26".
21
+
1. If work on an issue or task will start within the next 2 sprints, assign it to the appropriate sprint during Sprint Planning meetings. Work planned further than 2 sprints out does not need to be assigned to a sprint and can be left in the backlog, unless there is a known due date or we want to make sure something starts at a certain date.
22
+
5. Project: This field is important because it ensures the issue is grouped with the correct project in our Project Board. If you are unsure of the project to choose, the Project Manager can help.
22
23
1. Projects associated with DIF work start with “DIF - “ followed by the project name.
23
24
2. Tasks related to overall ODI infrastructure changes not tied to a specific project can go in the appropriate Infrastructure projects. This should be used by DSE team members only.
24
25
6. Milestone: Most DIF projects have Milestones which map to our project timelines. There is a search function which can help identify the correct milestone for the work being done. The Project Manager can help if you are not sure of the correct milestone.
25
26
1. Note: If a project repo does not have milestones created (for example the ODI data-infrastructure repo) then this can be left blank.
26
-
7. Due Date: Assign a due date when the work needs to be completed by, if applicable. If there is no set due date this can be left blank.
27
+
7. Due Date: Assign a due date when the work needs to be completed by a certain date, if applicable. If there is no set due date this can be left blank.
27
28
8. Status: Assign a status on the current state of the issue. See below for status options.
28
29
4. Pull Requests: Add phrase “(Fixes/Closes/Resolves) #xx” to ensure the referenced issue gets closed when PR is merged
29
-
1.Review “Open PRs” tab during stand up
30
-
5. Make sure to fully close an issue when completed.
30
+
1.We will review “Open PRs” tab during stand up.
31
+
5. Make sure to fully close an issue when completed by scrolling to the bottom and choosing "Close Issue".
31
32
32
33
33
34
## Size Definitions
34
35
35
36
**Tiny**
36
37
37
-
- Easy task, something that can be completed in about an hour. It may not require issue creation but could use as a reminder to complete the task later in the sprint (if something takes less than 30 minutes, no need for an issue).
38
+
- Easy task, something that can be completed in about an hour. If something takes less than 30 minutes, no need for an issue unless it will help serve as a reminder to complete something.
38
39
- Example: Sending a follow-up email
39
40
40
41
**Small**
41
42
42
43
- A task that can be completed in one day
44
+
- Example: Reviewing documentation on an API to determine how to onboard a new data source.
43
45
44
46
**Medium**
45
47
46
48
- A task that can be completed in about a week
47
49
- More complex but still straightforward to complete
50
+
- Example: Creating a staging or intermediate data model for a source that is well-understood and does not require complex logic.
48
51
49
52
**Large**
50
53
51
54
- A task that can be completed in 2 or more weeks
52
55
- Increased complexity, may require slower manual work or unknowns that require research and discovery
56
+
- Example: Writing an API script for a new, unknown data source.
53
57
54
58
**X-Large**
55
59
56
60
- Tasks that may take a month or longer to complete
57
-
- Consider breaking up into sub-tasks if appropriate, or create a meta-issue when there are dependencies
58
-
- Example: Refactoring a code base
61
+
- Consider breaking up into sub-tasks if possible, or create a meta-issue when there are dependencies
62
+
- Example: Building a full set of end-to-end models for a new data source, including staging, intermediate, and mart models.
59
63
60
64
## Priority Definitions
61
65
62
66
**Urgent**
63
67
64
-
- Top priority
65
-
- Reserved for unexpected emergency items
66
-
- Putting everything else on backburner
67
-
- Aiming for completion ASAP
68
-
- Due Date assigned must be kept
68
+
- Top priority, usually reserved for unexpected emergency item.
69
+
- Putting everything else on backburner, aiming for completion ASAP
69
70
- Not assigned as part of regular sprint planning process
70
71
71
72
**High**
72
73
73
-
-Important, goal is to complete this sprint
74
-
-Due Date should be kept as much as possible
74
+
-Goal is to complete this sprint
75
+
-Must stick to Due Date if established
75
76
76
77
**Medium**
77
78
78
79
- Less important than High, aim to complete within 2-4 sprints
79
-
-Due Date is a target but OK to push back
80
+
-OK to push to next sprint if needed
80
81
81
82
**Low**
82
83
83
84
- Work on as time allows, may leave in backlog
84
-
- Due Date not required or kept as a reminder to check back and move out of backlog by a certain point in time
0 commit comments