---
# System prepended metadata

title: Workstream process update
tags: [process, ' in-review']

---

---
robots: noindex, nofollow
tags: process, in-review
---

# Workstream process update

## Summary
This process draws inspiration from [Shape Up](https://basecamp.com/shapeup) by basecamp. In particular it draws on the ideas of ["Shaping"](https://basecamp.com/shapeup/1.1-chapter-02) a project before work begins. This is not a proposal to fully adopt the Shape Up process, but instead to draw inspiration from it and apply it to solve some challenges we face. 

## Motivation
* Workstreams are too vague and ongoing
    * There is no clear start and end
    * Features have to be "fit" into Workstreams
	* Sometimes features span multiple Workstreams
	* Ongoing areas encourage further investment and time even if it isn't warrented
* We desire more clarity
    * Need to know what work is on going and who is working on it
    * Need more scoping and consistency on proposed work
* Too many workstreams
    * Makes it feel like all 9 need to be active, which they don't
    * Sometimes we need to focus on something specific instead

### Organize work primarily around **Projects**
- Engineers will no longer join unbounded, long-running  **Workstreams** 
- Engineers will join clear, scoped, time-bound **Projects** 
    - Typically 1-3 engineers per project
    - Typically 1-3 weeks per project
- In ADO
    - Projects === Features
    - Can be grouped by Epics in ADO if necessary
:::warning
OPEN ISSUE: Can we just use GitHub for tracking work?
Still open, we can look into this more later. 
TODO: Setup discussion next week (consider windows terminal, consider typescript, consider vscode, WinUI).
If we do sync between both, what is the source of truth?
:::


Pulling from the [Big Picture Product Process](/fzE2jx1HSVCy3GNOyS-c9w?both), **Projects** are the way we organize work that will help us meet our quarterly goals (OKRs). 

Conceptually work is motivated as follows:
```flow
ps=>operation: Product Strategy
(2-5 years)
pr=>operation: Product Roadmap
(1 year)
okr=>operation: OKRs
(3 Months)
proj=>end: Projects
(3 Weeks)

ps->pr->okr->proj
```


## Details

### What are projects?

Projects are (quotes pulled directly from [Shape Up](https://basecamp.com/shapeup/1.1-chapter-02#property-1-its-rough))
- Problems
    Projects are problem focused. It is clear from the Project description what the problem being solved is and why we need to solve. Any relavent customers are called out. 
- Rough
    >Work in the shaping stage is rough. Everyone can tell by looking at it that it’s unfinished. They can see the open spaces where their contributions will go. Work that’s too fine, too early commits everyone to the wrong details. Designers and programmers need room to apply their own judgement and expertise when they roll up their sleeves and discover all the real trade-offs that emerge.
- Solved 
    >Despite being rough and unfinished, shaped work has been thought through. All the main elements of the solution are there at the macro level and they connect together. The work isn’t specified down to individual tasks, but the overall solution is spelled out. While surprises might still happen and icebergs could still emerge, there is clear direction showing what to do. Any open questions or rabbit holes we could see up front have been removed to reduce the project’s risk. 
- Bounded 
    >Lastly, shaped work indicates what not to do. It tells the team where to stop. There’s a specific appetite—the amount of time the team is allowed to spend on the project. Completing the project within that fixed amount of time requires limiting the scope and leaving specific things out.


> Taken together, the roughness leaves room for the team to resolve all the details, while the solution and boundaries act like guard rails. They reduce risk and channel the team’s efforts, making sure they don’t build too much, wander around, or get stuck.

For more information on actually shaping projects see this document: 
- [Shaping a Project](/kX02SXVbS6KzMOQd56i6Cg)

Template for Projects can be found here: 
- [Pitch template](/GAUYjmVZSNibiTOhxOiQ_w)

### Example Projects
- Single react-focus package
- Upgrade path w/ codemods
- Converge the repos
- Dual screen support
- Bundle size PR gate
- Render time PR gate


## Rhythm of the business

### Background
Below are some constraints, desires, history, and examples to help inspire and motivate our rhythm.

#### Constraints:
- Need to fit within Quarterly OKR cycle
- Need to provide status update to Teams bi-weekly sprint cycle
    - Everyother thursday Teams has a review of what was completed this sprint and what is scheduled for next sprint 
- Need to fit in within 2 week sprints
- Need to provide updates to the Monthly MBR long-running KPIs
- Need to publish regular (monthly/bi-weekly?) AOLs

#### Desires:
- Monthly update to community
- Sprint planning meeting for Fluent UI

#### History:
- We used to send Quarterly communication to Fabric community (newsletter)

#### Examples:
- [Typescript 3.7 Iteration plan](https://github.com/microsoft/TypeScript/issues/33352)
- [VSCode February Iteration](https://github.com/microsoft/vscode/issues/90371)

#### ROB Proposal
As background, the Shape Up proposes a [6 weeks work 2 weeks catch up](https://basecamp.com/shapeup/2.2-chapter-08#six-week-cycles) cycle. We can't really fit into that schedule as this would make our cycles 2 months long causing issues with the Office Quarterly cycle. Also 6 week long projects would likely cause grief for the Teams 2 week sprints.

In order to meet our constraints above and also leverage the Shape Up model, we can:
- Use a **3 week focus 1 week catch up** cyle. 
- Have a **2 week planning meeting** that acts both
    - An initial meeting to plan and decide on Projects for a cycle
    - A check-point half way through the cycle to check in on whether Projects are converging as expected

The 4 week cycle fits nicely within a month, which is 2 sprints. It also fits cleanly into Quarter for our OKRs and works with the MBR rhythm. 

The 2 week planning meeting helps us integrate with bi-weekly/sprint cadence that Teams and other folks in Office use. 

Setup:
- **Prior to the first week**
    - We review pitches for shaped Projects and decide what to focus on for the next cycle
    - Engineers are fit to Projects depending on needs and thier interests
    - Planned work is enumerated and communicated to partners

The weeks of the cycle:
1. **First week** 
    - Work starts on Projects assigned to this cycle
    - Engineers are able to focus on work, interuptions are kept to a minimuim
    - Progress and status is tracked in a single HackMD per project
1. **Second week**
    - Sprint planning meeting happens
        - Project leads come report on Project progress
        - [Shape Up: Show Progress](https://basecamp.com/shapeup/3.4-chapter-12)
    - Work continues, still heads down
1. **Third week**
    - Projects complete and area merged/released
    - Ideally projects complete early this week 
        - If you aren't going to finish early, you're going to finish late
    - If Projects do go long
        - There is a week of buffer to finish out
        - Work to reduce long running projects over time
        - Discuss why it went over in retrospective
1. **Fourth week**
    - Hold retrospectives for Projects
    - Engineers switch to task such as:
        - Clean up and Refactoring
        - Bug fixes and code review
        - Shaping future Projects
    - Send out an AOL / Communication annoucing the work that was completed    
    - Plan the next cycle
    - Breathe. 

## Drawbacks

Potential issues:
- Any change has cost. Is introducing this change worth it?
- ~~If a project ends very early, or projects do not end at the same time it will be difficult for folks to move to another project~~ (solved by fixed schedule)
- Without requiring tasks it will be harder to measure the incremental progress of projects
- Partners won't have sprints or task burndown to predict progress
    - Goal: find a better and more accurate way to provide status

<!--

:::warning
Paul: 
- Product Discovery
https://microsoft.sharepoint.com/teams/MicrosoftSignal/SitePages/DevX-Signal-Case-Study.aspx
- How do we identify the problems to be solved?
- Car dent vs Rat problem (Customer development)
    - Motivation of the customer
        - Car dent, no big deal, eh, i can live with it
        - Rat problem, omg I found a rat in the house eating our cereal. Behavior will change immediately. 
:::

## Needs/notes:
- Let's setup for success, try not to be too ambitious
- Styling and themeing a good canidate for shaped project. Good quick win.
- Idea: have small projects to shape future things. Especially in the component space. 
- Paul: 
    - Every Weds, here is where we are with our OKRs
    - Every week on Monday PM AOL, sometimes has what engineering is doing
    - Monthly MBR - Long running KPIs Debbie wants to have an understanding of how our OKRs impact these KPIs
    - Used to send Quarterly communication to Fabric communication (newsletter)
        - Tie this to external communication, don't also communicate internally. 
        - How to make external communication easy
    - VSCode gives kudos to contributors, how do we do this?
        - Flipgrid, tweet PR complete, contributions
    - Don't be dogmatic, be the clear customer choice. Always get better. Welcome contributions.
- Idea: AOL can be project description and high level status
    - Checkpoint at end of 2nd week to update project status
- Rekha
    - Teams contraint on bi-weekly sprint
    - Everyother thursday teams presents what we completed this sprint and what we are tackling next sprint
        - Do sprint planning on Weds
            - either this is checkpoint mid way
            - or identifying what we are starting next month
        - OK not burning hours
    - Don't disrupt teams process it's working
- Levi
    - Want a sprint planning meeting for Fluent UI
-->
<!---
<br/>
<br/>


:::warning
Scratch pad below
---
---
:::
## Appendix


#### *Draft* list of updated workstreams with project ideas: 
Projects in brackets [] are classes of projects, not specific ones.
<details>
<summary>Design to Code</summary>

- UI Builder (is this docs?)
- Figma Plugin
</details>
<details>
<summary>Performance Tooling</summary>

- Bundle size stats
- Bundle size PR gate
- Render time stats locally
- Render time PR gate
- Perf charts in docs
- Bundle size charts in docs
- [Flamegrill (scope this..)]
</details>

<details>
<summary>Accessibility Tools</summary>

- Dev loop catching issues
- PR Gates
</details>
<details>
<summary>Component Work</summary>

- [New components (Table, SideNav, Toast, etc)]
- [Component/utility updates (renames, features, etc)]
- Single react-focus package
</details>
<details>
<summary>Telemetry</summary>

- Converge v0 v7 telemetry approaches
- Split screen support
</details>
<details>
<summary>Theming (& Composition)</summary>

- CSS Variable Styling System
- compose() function and model
</details>
<details>
<summary>Docs & Ecosystem</summary>

- Info JSON Generator
- Allow M365 product teams to discover/share components
- Upgrade path w/ codemods
- Simplified new repo scaffolding
- Templates for "new package" or "new component"
    - Packaged and auto updated
</details>
<details>
<summary>CI & Engineering System</summary>

- Converge the repos
- [Github Bot scoped projects]
</details>
<details>
<summary>Docs [Mathieu]</summary>

- Ship new public website
</details>
<details>
<summary>UNKNOWN STUFF</summary>

- Open UI
    - FastDNA web components will be built in Open UI specs first
    - Shared component schemas will go here
    - Shared design tokens will go here
- npm package definitions
- Specs for components
- Icon story (@uifabric/icons, file type icons, product icons)
- Working with {partner} to help with {thing}
- repo deprecations cleanup
</details>

---


:::warning
TODO: What is the output of a shape up session?

Raw idea -> Tangible idea -> Shaping session -> Start work

Seperate out messy discussions and investigations from engineering work. 

1 project per IC


Output:
- ICs put the tasks in ADO
- Customer needs validation
- David: Ensure work with all partners
- Levi: Ensure the architecture fits with other projects
:::




---
1. Raw idea/opportunity/problem is identified. 
1. A team member experienced with the problem space works on shaping the raw idea into a clearly defined Project.
1. On-deck Projects are considered at monthly iteration boundaries.
1. A small (1-3) number of engineers join the Project.
1. Engineers self organize and define whatever tasks are necessary to complete the project. There are defaults for how we break up the work, but also freedom for the engineers to organize how they see fit.
1. Engineers execute, reporting status up regularly to the larger team.
1. Project gets completed, engineers move on to next project, ideally there is an opportunity to work in another workstream if desired
1. If project finishes early, engineer is free to clean up code, fix issues, or start shaping/investigating a future project they care about. Ideally this is self-directed work.
-->