Skip to main content

Process Charter

Sprint Process​

Ceremonies​

Sprint Kickoff​

  • Purpose: Product and engineering work together to pull a set of prioritized of “ready to start” work into the sprint
  • Cadence: first day of the sprint
  • Roles: Facilitated by Eng Lead, attended by entire team
  • Assess unfinished work from the last sprint:
    • If tickets are no longer relevant, closeout or move to the backlog
    • If tickets need to roll over, close the last sprint and move to current
  • All tickets should be pointed (unless super trivial)
  • Identify the team’s three-sprint average velocity (story points completed per sprint)
  • Engineering lead works with PM to pull in tickets with a story point total at or slightly above the team’s average velocity
  • Tickets should be prioritized within the sprint (vertically in the To Do swimlane)
  • This meeting should be short in duration (30 mins), as all tickets should be vetted, sized, and pointed during Backlog Refinement

Backlog Refinement​

  • Purpose: Product and engineering work together to ensure tickets in the top of the backlog (ideally going out a few sprints worth) are in “ready to start” status -- properly vetted, sized, prioritized, and pointed.
  • Cadence: varies depending on the health of the backlog - could be ad hoc or regularly scheduled
  • Roles: Facilitated by Eng Lead, attended by the entire team or based on which backlog items are being discussed (specific features vs more general)
  • The PM should come to this meeting having prioritized work in the backlog. Eng and Prod then work down through the list, going through each ticket to ensure Eng has the right amount of detail and clarity.

Standup​

  • Purpose: Quick 15 min meeting to inspect progress toward the sprint goal.
  • Cadence: daily
  • Roles: Facilitated by Eng Lead, attended by the entire team
  • Pretty simple -- what did you do yesterday, what are you doing today, are you blocked, is what you’re working on going to make it
  • Opportunity to identify bottlenecks (pull requests backing up, QA backing up) and swarm
  • Should bring up the burndown chart every few days to see if things are on track

Retrospective​

  • Purpose: Opportunity for the team to inspect the sprint process and surface actionable ways to make it more efficient and effective
  • Cadence: last day of the sprint
  • Roles: Facilitated by the PM or Eng Lead, attended by the entire team
  • Meeting sections
    • Bring up the previous retrospective and review action items
    • Sprint inspection - the facilitator pulls up a shared workspace (Miro) and the team adds sticky notes with comments to the following sections:
      • What went well
      • What could have gone better
    • Identify action items to implement during the next sprint
  • Some general guidelines:
    • Don’t make it personal, don’t take it personally
    • Listen with an open mind
    • Everyone’s experience is valid
    • Focus on improvement, rather than placing blame
    • If something didn’t work or isn’t working, how would you like to see it change?

Development Lifecycle​

Branching​

  • If possible, include the Jira ticket number in the branch name: VEL-123-some-description This allows the Jira/Github integration to link the ticket to the branch.

QA & Release Process​

For now, given that we don’t have a dedicated QA resource, the engineer who submitted a pull request will be responsible for facilitating the QA and release process. A few things to keep in mind for both backend and front-end:

  • For features/changes with community impact, @ GJ and your PM in #widgies

  • It’s up to you to usher your feature through the process. If you haven’t gotten a review on a pull request in 3 or 4 hours, definitely nag your teammates!

  • Your ticket is not considered complete until you have merged your branch into main/master and your work is deployed to production. You are responsible for making that happen.

Backend​

  • Create a pull request against the main branch and post it to #team-prod-eng-private
    • If there’s a team member who would be best suited to review, give them an @
  • After a PR approval and automated tests pass, merge and CI/CD will automatically deploy

Front-end​

  • Create a pull request against the master branch and post it to #widgies
    • If there’s a team member who would be best suited to review, give them an @

  • In parallel, start facilitating the QA process. The key here is to use your best judgement.

    • If the feature/change is small and straight forward, QA yourself in the Vercel preview branch
    • If the feature touches any major functionality like auth, query execution, dashboard building, etc - be sure to test for regressions.
    • For high impact changes, reach out to your team lead for more QA help
    • If there are acceptance criteria that need sign-off from Product, give an @ to your PM
    • If the feature is design heavy, give an @ to your designer

  • If the PR review process results in significant code changes, be sure to run through the QA process again

  • Once you have a passing test suite and QA sign-off, merge to master and CI/CD will automatically deploy