diff --git a/WaysofWork.md b/WaysofWork.md index 9971210..75e7566 100644 --- a/WaysofWork.md +++ b/WaysofWork.md @@ -23,7 +23,7 @@ These are issues as normally used, they are created in their corresponding repos When created in another repository try to still apply these rules as much as possible but do attend first to specific issue requirements present there. - Duration: strive to create issues that do not (or are not expected to) exceed a month, -- Add to the Project [DSH unified board proposal](https://github.com/orgs/alan-turing-institute/projects/111) during creation or afterwards +- Add to the Project [DSH unified board proposal](https://github.com/orgs/alan-turing-institute/projects/111) during creation or afterwards, do this even if you have not time to fill any further fields. - Mention in the body or comment the Story this issue contributes to if possible - Create the issue - Fill the following project fields via the dropdown menu (you can also go to the [project table view](https://github.com/orgs/alan-turing-institute/projects/111/views/3) for it) @@ -32,20 +32,23 @@ When created in another repository try to still apply these rules as much as pos - Backlog: if it has been agreed as necessary work - Planned: agreed and we know when to address it or by when it needs done - Points (effort): assign a value effort from 2 to 9. A value of 1 typically means that the task is so short it would be better merged with another, a 10 means that it is probably best split in more than one issue (maybe it needs to be a story instead of an issue); if you really want to assign a 1 or 10 (cannot be merged or split) do so + - FTE: estimate % of person time while ongoing this issue will take, for example 2 people dedicating 1 day a week, wiht an issue duration of a month would be about 0.26. + - Important! Update this when closing - Add planned dates when known + - Add actual dates when closing - Story Effort: leave blank, does not apply to base issues - - Team Accountable: who is the momentum generator for this task? - - Project/Funding: which project within DSH does this task belong to? + - Team Accountable: leave blank, this is already in the Story (But do add an assignee) + - Project/Funding: leave blank, already in Story ##### **I do not know what Story this issue belongs to**, Should I create this issue?** All work and the related issue should clearly contribute to agreed upon goals, and their corresponding stories. If you are unable to assign an issue to a story consider whether to create it in the first place, -if you think it is work that the project needs add it for discussion during the next weekly meeting or open a thread in the corresponding channel. +if you think it is work that the project needs add it for discussion during the next weekly meeting, you can add it in the blockers section, or open a thread in the corresponding channel if you need to address it earlier. When the team agrees that it is indeed necessary create the issue, include the label 'For Prioritisation' (if created in this repository), add it to the project and do not set a status, never include it in Backlog, Planned or any other status at this stage. -During the next monthly meeting the whole team will discuss its prioritisation, -or review the project roadmap if it turns out it is not reflected the actual work being carried out or necessary for the project's success. +If the issue is still Story-less by the next monthly meeting the whole team will discuss its prioritisation, +or review the project roadmap if it turns out it is not reflecting the actual work being carried out or necessary for the project's success. ``` This situation may arise in the beginning, while we fully complete the roadmap and configure the repository, after that it should be rare. @@ -55,6 +58,7 @@ The next monthly meeting should be longer, at least two hours, and focused on th At any given moment the number of active stories you are directly working on should be fairly limited, do not worry about having to keep many in mind to choose the right one (take it to the RPM otherwise and they will help out) + #### Story issues Stories are only created in this repo (data-safe-haven-team) and are "issues of issues", @@ -65,6 +69,8 @@ Stories should not be created without consensus, if you DO NEED to create one to It is the responsibility of the Accountable team or person, with help from the RPM where necessary, to create and complete a story. +Active stories are expected to be updated at least once a month by the RPM with help from the Accountable person, updates will be based on issue updates and the weekly reports done by the team in the weekly meeting notes. + In the body of the issue: - Specify the goal this story refers to - Describe what the work is and what it will achieve @@ -199,6 +205,7 @@ by default it is organised by team accountable and shows only the stories each i Dragging and dropping a story in the calendar will automatically fill in or modify the planned start and end. +Creating a new issue from this view will automatically have its accountable team filled. #### Roadmap - Tasks @@ -211,9 +218,19 @@ It allows to quickly view the total effort (as a sum of points) that each team h Likely to be the most day to day view, it shows issues by status. For simplicity only one view exists, where task level issues and stories cause confusion use the Story label to filter. +By default it is filtered to show only tasks. What statuses to use and how can evolve with use, the most important rule to follow is to respect the backlog as agreed upon work. +It is recommended task issues are updated weekly. + +#### Workload + +A table view filtered so workload can be analysed, +by default grouped by Accountable Team and filtered by planned stories. + +It shows the sum of current FTE. + #### Table How to best use it will be discussed and developed together, no direct or immediate use yet (do suggest!) @@ -238,6 +255,9 @@ therefore the focus is in maintaining up to date repositories and communicating Meeting time should be focus on collaboration and group decisions. +Scheduled and fixed time together is key for fostering collaboraiton and discussion, but has also proven to provide great flexibility and capacity to address issues as they arise. +In a setting where finding a calendar slot that everyone can make is very challenging, sometimes requiring a month or longer, having 2 weekly and 2 monthly recurrent shared times slots has proved highly benefitial. + ### Weekly meeting Key facts - Mondays 10.00 to 10.30 @@ -266,7 +286,10 @@ Key facts - Attended by Project working team - Purpose: work together in issues identified during weekly -Co-working time is an unstructured hour for synchronous work +Co-working time is an unstructured hour for synchronous work. +It allows to address matters as they arise, team members can propose any topics or task to work together on during the week or directly at the start of the meeting. + +It has proven useful as well to quickly address team wide discussions when a monthly meeting is still too far ahead, or to collaborative write funding applications. ### Monthly meeting Key facts