Data Teams Principles

Last updated by Yana Wang on 3/14/2022 7:12:55 AM This content is over 788 days old.

Overall principles and goals for monthly planning and retrospective across areas and projects

Principles

  1. Strongly recommend to keep charters to objectives (at least those driven by STCA) as 1:1, and keep a highly efficient cross-reference lookup across objectives and charters in order to facilitate rapid searching.

  2. A proposed mapping and refer between ADO WIT(Work Item Type) and Specs: 1 Objective ->(refer to) 1 project charter, m KRs -> 1 PM Spec/Func Spec, n story -> Design/Test Spec.

  3. Keep the Objective/KRs fully consistent in DSM ADO(link), Auriga ADO, changes should be updated first into Auriga ADO prior to DSM ADO, and set Projects Master Tracker (excel) obselete after it has served their purpose.

  4. All the OKRs in DSM ADO/Auriga ADO should be locked down before monthly planning, any changes must be highlighted and approved by all the stakeholders.

  5. DSM ADO will only focus on OKR level as the only place to be updated centrally for LT team, that can be referenced by corresponding Objective/KRs in Auriga.

  6. Auriga ADO will be kept with the hierarchical OKR, User Story, Task, Action for STCA sprint/scrum tracking.

  7. Teams can voluntarily collaborate to ensure the work, resource, priority balanced, align the approachs and process for new asks triage and DRI repair items addressing.

  8. An online retrospective meeting is required to review, identify and solve the top issues, but planning is not required and can be handled offline.

Planning Goal

  1. The priority and resource are tweakeded and balanced across teams and KRs.

  2. Forcast the completion rate of committed KRs and updated completion rate, committed work into DSM ADO.

  3. Cross-reference lookup between objective and charter.

    Note: User Story/Story points might be used to get the planning cut line, but at least task doesn't have to be broken down at that moment.

Retrospective Goal

  1. Highlights and lowlights.

  2. KR completion review.

  3. Run Restropectives.

Team Planning, Scrum and Retros

  1. Each team can autonomously orgnize the planning, scrum, retrospective and check scrum status.

  2. Capacity is still required for each team to keep it updated.

  3. Auriga dashboard still can be used/referenced but not required by team for monitoring the scrum and detecting potential issue.

Best practices for reference

TBD - will have a retrospective workshop after July to check what we learned.

Appendix

  1. PM prioritize work items by P1 70% and P2 30% at Story level. If there’s new partner ask in the middle of a sprint which has higher priority, the P2 stories will be postponed by default.

  2. Lead balance dev workload around P1 70% and P2 30% at Task level. Notice P2 tasks are still within a dev’s capacity and expected to be completed if not yield to higher priority work.

  3. P1 and P2 user stories must be ready to be started in this month. If there are predictable blockers, we should not plan them.

  4. By default, we will plan not over 100% load for each dev. But we will create P3 user story as backlog (suggested by PM). If people finish their planned tasks or their planned tasks are blocked, they can pick P3 user story. P3 user story will not be broken down in planning stage. Will only be broken down when it is picked-up.

  5. User story is created in month level. Namely each user story is suppose to be completed within this month. If we cannot finish all work within a month, split it in planning stage. But each splited story must have clear goal (accept criteria).

  6. Don't push/split a user story during a spring. Otherwise, it dashboard cannot reflect the real execution status.