Workflow Process

Ward Sandler
Ward Sandler
Last updated 

🎯 Objective

Create an environment where the Dev Team (DT) can consistently gets new features shipped and customer issues resolved while regularly communicating their progress and blockers.


☀️ Daily Workflow

  • First thing everyday look over pending PR reviews (BE / FE) so we're not blocking code.
  • Meet as a team every Mon & Wed to review updates, blockers, and questions for Task board and cycle work.
  • All non-cycle work should be listed on the Task board in the Backlog.
    • During DT meetings, anyone can advocate for working on one task over another.
    • We should assess capacity before assigning tasks to anyone.
      • After assigning, move task to In Progress
    • If a task is purely technical (i.e. the whole company doesn't need to know) add [Tech] at the beginning of the title.
    • If you need to handle a minor improvement/chore autonomously that will take 1/2 day or less, no need to wait for DT meeting or create a task. Do create the task though if the work is something other people need to know about.
    • Once you merge a PR into Staging, move task to FYI Done so everyone is notified.

♻️ Cycle Workflow

This process is loosely inspired by Shape Up
  • First shaping work is done (research > discussions > wireframes) which involves the LT initially and then the DT is brought in for initial feedback.
    • End result is a finalized Build Doc (example) with a time boundary (3 - 10 weeks) for building.
    • Point of time boundary is to cut scope as needed while building, not add on more time.
  • Handoff with the DT occurs ~1 week before build time starts.
    • Figma designs will be finalized after Handoff (DT will use wireframes to start)
  • After building starts, DT will work on various scopes. Should do a rolling QA (as needed) with entire company as scopes get finished with goal of them going live asap.
    • During a cycle DT's priority should be the cycle, not tasks. However, occasionally DT will be interrupted to work on an important task. If needed, the time spent on those interruptions can be added back onto the build time.
  • Before go live of any scope, everyone communicates to decide a date so comms work can be completed ahead of time (help docs, YouTube overview, announcements, etc).
  • Generally we won't do cycles back to back so there is time for everyone to cool off.

🚨 Issues

  • When someone notices an issue/bug, add a task to the [FE] or [BE] Issues list and assign an urgency:
    • [low] (we'll fix to it one day, it can wait indefinitely)
    • [high] (we should get to it within 5 business days)
    • [critical] (we should stop everything and fix this, all hands on deck)
  • If someone isn't sure if something is [FE] or [BE] feel free to ask Ward/Ryan
  • Issues are an exception where DT members can start working on them without waiting for the DT meeting. Just move the task to In Progress when starting.

⤴️ Pull Requests

  • Request a PR review from msupdatebot to automatically ping the DT campfire for reviews.
    • When reviewing code, please follow our guidelines.
  • If you want ST to QA test something, after you've moved the task to FYI Done, ping "@support" in the task comments asking them to test it. You should always personally test your changes in a Staging site as well.
  • When you're ready, merge Staging into Production. Do not merge into Production after 2pm ET or on Fridays at all (unless it's critical).
  • Should be submitting a PR every 1-2 days even if you're work is still in progress. Point is to get in the habit of pushing small chunks of work instead of waiting for every part of the task to be completed and to start getting feedback from other team members.