Explore the creation of a more structured iteration plan

[tschaffter]

I stumbled upon a VS Code iteration plan and I'm thinking about adopting a similar approach. The closest thing we have is our Sprint 22.09 board. What I like is:

• the Mark annotation that VS Code uses, which we could add to our Sprint board
• the grouping of ticket by products and features like "Workbench", "Accessibility"

I want to avoid duplicating effort that we already do. One improvement could be to add a column Mark or similar to our board to identify stretch goals, missing references, etc.

cc: @AmyHeiser

[AmyHeiser]

What I like is that you focus on what is delivered (working product delivered at an iteration). If you want to establish a cadence/metric for the team, a good thing to include is story points in the stories/features so that you can measure velocity (cadence) and better estimate what the team can complete in a sprint. This is similar to what I'm recommending to the other D&T teams, if you want to talk more on this let me know :) And something you'll want to keep in mind if you restructure anything.

…

On Sat, Sep 10, 2022 at 1:21 PM Thomas Schaffter ***@***.***> wrote: I stumbled upon a VS Code iteration plan <microsoft/vscode#160046> and I'm thinking about adopting a similar approach. The closest thing we have is our Sprint 22.09 board <https://github.com/orgs/Sage-Bionetworks/projects/39>. What I like is: - the Mark annotation that VS Code uses, which we could add to our Sprint board - the grouping of ticket by products and features like "Workbench", "Accessibility" I want to avoid duplicating effort that we already do. One improvement could be to add a column Mark or similar to our board to identify stretch goals, missing references, etc. cc: @AmyHeiser <https://github.com/AmyHeiser> — Reply to this email directly, view it on GitHub <#689>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2E5LYQKGY3UE2R3Q2DUI2LV5S7QPANCNFSM6AAAAAAQJNFMSA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

-- *Best,* *Amy Heiser (*she/her) D&T Program Manager Sage Bionetworks *Making science better, together*

[tschaffter]

Here is a list of current limitations and ideas for improvement

How to track sprint history

Background: I set the value of the task property Sprint to the target/deadline sprint, i.e. when the task is expected to be completed. For example, a possible value to Sprint is 22.09 (September sprint). GitHub does not allows to assign multiple values to custom metadata. One limitation is that tasks that span over multiple sprints are ill-tracked because only one value can be assigned and I use this value as the target completion sprint.

Another limitation is that the Sprint value is continuously incremented for tasks on which we are late in order for the task appears in the current project board. Updating the value of Sprint is not capture in any history so we loose information about the initial target end sprint. This information could be useful to improve our guess of how long a task would take to complete.

Options:

• Use GH labels to lint tasks to multiple sprints. For example, we could create labels such as sprint: 22.09, sprint: 22.10, etc. Multiple labels can be assigned to one task. In the Sprint board, we could filter and keep only the tickets that have a given label (e.g. sprint: 20.09). One benefit is that GH keeps track of the history of labels added to and removed from a task.

• Use two properties to track the start and end sprints. Yet, a ticket with the start sprint set to 22.08 and end sprint to 22.10 will not appear in the project board 22.09, despite the fact that we are working on the ticket in September while targeting completion in October. Yet, I think that we want to show to the stakeholder that we worked on that task in September?

Mark tasks that are considered as stretch goals

One idea I like about the VS Code iteration plans is that they mark the tasks that are considered as stretch goals for a given iteration.

Options:

• Maybe the best way to implement this feature is to create an iteration plan like VS Code does. In such plan, stretch goals could be identified by prefixing the tasks with an emoticon such as 💪.

• Alternatively, we could add the prefix 💪 to the title of the tickets. This information would then show in the project board. However, this is information is only relevant in respect for the current sprint. Therefore, we don't necessarily want to pollute our git history with an emoticon that only makes sense for a given sprint.

• We could create a task property Stretch Goal with the value yes or no. The value may need to be revisited when a task span more than one sprint. For example, a task marked as stretch goal in September may no longer be a stretch goal in October.

• Considering that we may want to assign multiple "mark" like 💪 (stretch goal), 🔴 (missing issue reference), etc., a more compact way may be to create a single task property called Marks that is set to accept an arbitrary string such as "💪🔴".

Validation of iteration plans

As part of the sprint preparation ceremony, it would be nice if each team member could show their approval with the sprint/iteration plan and the goals identified. This ensure that the team members have been informed with the goals and agree with them. For the September sprint, I asked Rong and Verena to drop a ✅ in Slack, but it would be better if we standardize this process and capture the information in GH.

Options:

• Create a "note" item to the project board and capture information about plan approval there. One potential drawback is that anyone can edit this information.
  

• Create a proper ticket and ask team members to drop a 👍 or similar on the original post. This could be one extra motivation for creating an iteration plan like VS Code does. This has the benefit that team members can only give their approval themselves. One potential drawback is that GH does not capture the removal of emoticon, but we could assume that this is an acceptable limitation.

Tracking changes made to a plan after its validation

The content of the project board can be edited anytime. It is common for me to add new (usually low-level) tasks that I didn't think about at the beginning of the sprint. New urgent tasks may also be submitted anytime, e.g. an urgent bug needs to be fixed. A limitation is then that the content of the project board may change after its validation by team members. Technically, we can always review the creation time of a task and compare it to the date when the iteration plan was approved. This information is just not made clearly visible at the moment.

Options:

• Do nothing if there is no need to surface this information clearly.
• Manually track tasks that have been created after the plan approval date, e.g. by listing such tasks in a ticket, e.g. an iteration plan ticket if we decide to create one. The extra effort required to capture this information may not be worth it.

Getting help from a bot

Some of the tasks mentioned above could be automated using a third-party GH bot. We could also create our own bot. For example, tasks added to a sprint plan after its validation date could be automatically added to a list by the bot. Creating a bot is a task I would like to explore at some point (maybe in 2023).

[tschaffter]

About sprint tracking: it should be fine to continue using the property Sprint as the target completion sprint. Considering the following two boards:

• Sprint/iteration board: Here we only show the items that we aim to complete by the end of the sprint. We may still be working on larger items that span more than one sprint and that don't show up in the table. It potential "blind spot" should be addressed by the second board (see below).

• Epic board: This board lists the Epics grouped by their Status (In Progress, Done, etc.). Thus, this board can be used anytime to know the Epics we are working on (this information missing from the sprint board).

[tschaffter]

About the "Mark" used by the VS Code iteration plan:

Mark	Description	Comment
🏃	work in progress	Already captured by the property Status
✋	blocked task	Already captured by the property Status
💪	stretch goal for this iteration	Sprint-specific mark
🔴	missing issue reference	All items are issues in our board
🔵	more investigation required to remove uncertainty	Global mark
⚫	under discussion within the team	We could do without for now
⬛	a large work item, larger than one iteration	Already captured by the property Status

Global marks could be implemented as Label:

• under-discussion or ⚫ under-discussion
• investigation-needed or 🔵 investigation-needed

The remaining mark for stretch goal is tricky because we can't associate this information to a specific sprint. One option is to add this mark temporarily. For example, we could create a label 💪 stretch-goal and assign it to a task in September. If this task is not completed and is added to October sprint as a non-stretch goal, then the label should be manually removed.

[AmyHeiser]

Does GitHub provide a burndown chart/story points or some estimation & tracking? This would be best way to show changes in the sprint after the start and helps show stakeholders progress on the agreed upon work.

[tschaffter]

GH boards offer some insights (see screenshot), including a Burn up / CFD chart.

https://github.com/orgs/Sage-Bionetworks/projects/39/insights

[tschaffter]

Take-home messages from our discussion with @AmyHeiser:

• The sprint GH board is preferred to defining the iteration plan in a GH ticket like VS Code does.
  • It is more intuitive to input the data with our current approach.
  • Using a ticket for the sprint plan would require to manually edit the ticket, which is less user friendly.
• The validation of the sprint preparation by the team can be captured in the meeting minutes.
  • During the sprint review, we should try to break down stories as much as we can instead of creating more tasks later during the sprint.
  • The creation of new tasks after the validation of the sprint would be visible in a Burn up chart (see below).
• It would be great to use story points (SP) as a tool to better evaluate the workload and complexity of tasks, even if we are a small team with engineers who do not work full time on the project.
  • Early investigation of story points is tracked in Explore the use of Story Points #471.
  • SP come in different flavors (e.g. points, T-shirt size).
  • Amy doesn't recommend to use number of hours for the SP.
  • @tschaffter to investigate the creation of a Burn up / CFD chart that uses SP with GH Insights.
• We will monitor the effect of the recent changes - e.g. new, comprehensive sprint board - before implementing new planning features (e.g. story points).
• @tschaffter and @AmyHeiser to meet sometimes next week or the week after to discussion sprint preparation and review.