Secure/Defend Stage: Planning process

How do we plan milestones together

Purpose of having a planning plan with action point:

• The Gitlab workflow has mapped out a work process with timeline, but it is not clear enough for us what exactly to do among all disciplines. We would like to start talking about:
  • What is needed to be done during every planning step: ex understand issue, labelling issue, weight issues
  • In what format/way we are going to do the tasks: ex using issue board async or sync meeting
  • What is the output of each step: ex, an issue board with correct/clear labelling and weight The final goal of having a clear process is that before a milestone starts everyone knows exactly what are the issues need to be done so that everyone can plan their daily work better

Following table has listed out some ideas, please take a look and don't hesitate to leave comments, consider following questions

• Is this a good approach? Everything listed out in detail?
• Is there something missing at every plan step? As a UX, do you need to know more in order to get better planning?
• Is there something could be improved at every plan step? Ex, weighting might not be good for UX issues?
• Is there any situation is not covered and you think is important? Ex, how do plan UX only issues (Pajama, UI, scorecard issue) into planning?
• Here is the original google doc, if you prefer to read/comment there. I tried to make it easier to read with the table and markdown, but not as good as it shows in g-doc... sorry for that

Next step:

We all take a look at it and think through after we have an agreement we can bring it to the PM

Gitlab milestone plan process	Action Point	Output
y month M-1, 4th (at least 14 days before milestone m begins): - Draft of the issues that will be included in the next released (released 22nd of next month).	* PM announces that Issue Board Next Milestone is prepared for milestone m, ready to review * UX, UXR, Devs propose issues they think might be good for milestone m as well (or this step is earlier) by adding them to board. Proposed issues should * (Note: in order to make it easier for the PM to know that certain issues are proposed for the next milestone, we could use a label “prepared for milestone m ” something like this?)	An Issue Board Next Milestone with drafts issues are ready to be viewed/discussed
- Start capacity and technical discussions with engineering/UX.	* Set a deadline to discuss (could be a slack bot) * Discuss issues: UX/UXR/Devs will do the following: * Everyone has a basic understanding of what are the issues (Could be comments, could be a sync meeting) * UX could keep using the spreadsheet; if it is too much maintenance, we could use the issue board * Labelling issues: * After discussion, if issue is clear, there should be labels which make PM know it is clear (suggestion see output part) * After discussion, if issue is NOT clear enough to work on, there should be a label that makes PM know it is NOT clear. (suggestion see output part) * Weighing issues: * UX/UXR/Devs add weight to issues (take the manage-group-weight-system as an example) * UX/UXR/Devs also should inform PM what is the average Capacity (including planned PTO) for the milestone m * Deadline reminder (could be a slack bot)	An Issue Board Next Milestone with issues of correct labels and weights: * Build Track issues: Clear-and-is-ready-to-work (means that UX is ready, dev knows what to work on) will be labeled with workflowscheduling * Build Track issues: Un-clear-and-Can't-be-worked-immediately, need to be pointed out and giving label workflowplanning breakdown * Validation Track issues : Clear-and-is-ready-to-work (means it is clear enough for UX/UXR to pickup vlidate the problem result could be clear problem statement/breakdown issues or draft solutions for UX/UXR to continue work on it), will be labeled with workflowproblem validation Clear-and-is-ready-to-work (means it is clear enough for UX/UXR to pickup work on the draft solution, result of this issue will be design ready for dev to work on ), will be labeled with workflowsolution validation * Validation Track: Un-clear-and-Can't-be-worked-immediately,need to be pointed out and giving label workflowvalidation backlog Note: the idea here is that UX has its own issue, an UX issue is always a validation issue. When there is a build track issue, it equals to "UX ready".
By month M-1, 13th (at least 5 days before milestone m begins): * Release scope is finalized. In-scope issues marked with milestone m; label deliverable applied. * Kickoff document is updated with relevant items to be included.	* PM organize the Issue Board Next Milestone based on the feedback * For clear issues, label is updated correctly, move to Issue Board Milestone M (if the milestone is set, issue board auto-update?) * For unclear issues, either make it clear in those 5 days or move it to Milestone m+1 * UX/UXR/Dev inform PM what will likely fall "below the line" based on capacity and prioritization. * Consider how much “weight” should be included in milestone, maybe add more or remove some issues and finally “draw the line” which everyone agrees * PM(or a bot) announce it to the team everything is ready: * Issue Board Next Milestone is empty now an issue Board Milestone M is ready to go	A finalized Issue Board Milestone M * Prioritizations is clear (either with a label (P1, 2,3,4) or just use issue board orders: top to down indicate priority) * Weights/capacity are agreed by all
- UX/UXR/Devs can assign issues to themselves - PM schedule kickoff meeting scheduled and make team aware	* A finalized Issue Board Milestone M board with assignees * Kickoff meetings in team calendar
By month M-1, 17th (at least 1 day before milestone m begins): - Group Kickoffs calls recorded and uploaded.	* People join the kickoff meeting	Kickoff meetings record in youtube channel
On month M-1, 18th (or next business day, milestone m begins): Kick off! 📣 - Company Kickoff call live streamed. - Development on milestone m begins	* Everyone starts working in milestone

This is the weight system used by Devop::Manage, we can also discuss how do we think about this UX weighting system:

Weight	Description (UX)
1	Mostly small to medium UI changes, smaller UX improvements, without unanswered questions
2	Simple UI or UX change where we understand all of the requirements, but may need to find solutions to known questions/problems.
3	A simple change but the scope of work is bigger (lots of UI or UX changes/improvements required). Multiple pages are involved, we're starting to design/redesign small flows. Some unknown questions may arise during the work.
5	A complex change where other team members will need to be involved. Spans across multiple pages, we're working on medium-sized flows. There are significant open questions that need to be answered.
8	A complex change that spans across large flows and may require input from other designers. This is the largest flow design/redesign that we would take on in a single milestone.
13	A significant change that spans across multiple flows and that would require significant input from others (teams, team members, user feedback) and there are many unknown unknowns. It's unlikely we would commit to this in a milestone, and the preference would be to further clarify requirements and/or break in to smaller Issues.