Skip to content

Latest commit

 

History

History
175 lines (116 loc) · 11.2 KB

workflow.md

File metadata and controls

175 lines (116 loc) · 11.2 KB

Tech Portfolio Workflow

Ceremonies and Activities

We use the term "sprint" to refer to the ceremony cycles, even though they aren't strictly Sprints in the Scrum sense. These can all be found on the shared TTS Tech Portfolio calendar.

Any ceremony can start with a standup if needed.

Sprint Planning

Purpose: Have the Ready (Sprint Planned) column represent all cards that will be started this Sprint.

Meeting Flow:

  1. Due Date Review: Look for cards that have upcoming due dates. Move into Ready (Sprint Planned) as necessary to complete them in time.
  2. Review New cards: Move cards into Backlog (Sprint Staging) that you would like to discuss adding into the Sprint. Move the rest into Icebox.
  3. Review Icebox cards: Move cards from Icebox into Backlog (Sprint Staging) that you would like to discuss adding into the Sprint.
  4. Get Ready: Move cards between Backlog (Sprint Staging) and Ready (Sprint Planned).
    • Ready (Sprint Planned) should represent the highest-priority issues that haven't been started.
    • There should only be as many assigned to each person as they think they will be able to start this Sprint. Keep the following in mind:
      • What to work on
      • Upcoming leave
      • Other commitments (training, working groups, etc.)

Prioritization

Use the following considerations for how to prioritize cards moving towards/into Ready:

  • Due date
  • Force-multiplier / quick win / high value
    • Prioritize reducing Tech Portfolio pain points / toil before those of our customers, in the spirit of "put your own oxygen mask on first, before attempting to help those around you."
  • Continuation of things you've already been working on
  • Solve active pain points over nice-to-haves

Stand-ups

Purpose: Ensure folks are making progress within their assigned Initiative areas and that people aren't blocked.

Meeting Flow:

  1. First 15 minutes or less: For each participant, give status updates.
    1. Filter board by assignee:<GITHUB_USERNAME>
    2. Give status updates on issues from right to left (Blocked/Watching through In Progress), top to bottom in each column
    3. What they plan to start next
    4. Raise any:
      • Current blockers
      • Things that need feedback
      • Help needed
    5. Confirm there are no issues missing to represent recent/current/upcoming work
    6. Review of calendar items that others might benefit from attending or knowing about
  2. Folks who don't need to stay for subsequent items are welcome to drop.
  3. Revisit parking lot items.
  4. OpsRotation person leads looking at any any pull requests that would be useful to review as a group.

What to work on

Work on cards assigned to you:

  1. With upcoming due dates
  2. Right to left on the board

See also: guidelines for external contribution

Lunches

Purpose: Team bonding/culture-building.

Optional. We talk about whatever we want, work-related or not.

Co-working

Purpose: Time set aside to work through tasks as a group (full or partial team)

Grooming

Purpose: Ensure that cards that are groomed before they're closed, ideally before they're started.

Meeting Flow:

  1. New Card Review - Teammates will brief others on the new cards they created and the group will decide where the card should go to Icebox or Backlog (Sprint Staging).
  2. Teammates will order the cards within their initiative in the Icebox based on their own criteria
  3. Review non-groomed issues right to left, grooming each

Icebox Thaw

Purpose: Remove stale issues from the Icebox.

Retros

Purpose: An opportunity for the team to inspect itself and identify possible improvements.

Notes

The board

Purpose: Show what is and isn't being worked on, and to help keep ourselves from taking on too much at once, individually and collectively.

The board structure is inspired by Kanban.

Initiatives

These are our categories of work. There is an Initiatives column that is there to help with filtering.

Cards

Also known as an "issue".

Purpose:

  • Representing chunks of work
  • Remind ourselves what problem we are trying to solve
  • Establish a scope that is completable sooner than later

A card should be created when a task:

  • Is the responsibility of the Tech Portfolio (versus something like a personal HR-related task)
  • Will take more than 30 minutes
    • Shorter tasks can be added (such as "schedule meeting around X"), but is not required
    • Not necessary for things like recurring or TTS-wide meetings. For example: we don't have cards for each of our ceremonies.
    • Beware of tasks that seem quick ("email someone about X") but commit you / the team to follow-on conversations/work.
  • Would otherwise be lost as an action item in an email, meeting notes, Slack, etc.

Other notes:

Assignment

Issues default to being assigned to the corresponding Initiative owner. That person is welcome to ask for someone else to take it, such as if:

  • A particular skillset is needed
  • They don't have capacity to finish it by the due date
  • It falls under someone else's role
  • The other person is specifically interested (for personal growth, etc.)

The Project Manager will be responsible for resolving any uncertainty around assignment.

Labels

We have a couple set types of labels, which are configured as code. Beyond those, you are welcome to add whatever labels are useful to you.

Grooming status

Purpose: Consensus on the problem that will be solved and the work expectations (timeline, artefact, etc.)

The grooming status is represented with the g: labels: g: initial → g: final → g: accepted. An issue is considered "groomed" (g: accepted) once it has been:

  • Given the following labels:
    • Initiative (i: <whatever>)
      • s: months should be broken up
    • Size (s: <days|weeks>)
  • Added to the board
  • Assigned
  • Reviewed by another member of the team for clarity, accuracy, and being realistic

Implementation Steps aren't required at this point. See also: the grooming sprint ceremony.

Columns

Ideally, issues move left to right, with the exception of Feedback/Waiting and Blocked/Watching.

Column Description Ordered? Max per person Issue entrance criteria
New Newly created Issues land here automatically. N
Icebox Y, within each Initiative (roughly)
Backlog (Sprint Staged) Issues to be considered for the next Sprint. N 4 Assigned
Ready (Sprint Planned) Issues to be worked on next. Populated during the Sprint Planning ceremony. Y Groomed
In Progress Issues that are being actively worked on. N 3, though fewer is recommended Groomed
Feedback/Waiting Issues temporarily moved into this column. Expect to move in and out quickly. Something that is actively being worked on and it is with someone else for the moment. N Explanation of what it's waiting on
Blocked/Watching Issues that are waiting on someone outside the team; out of our control to get done. Want to keep an eye on it, but not likely to be responsible for it to be done. N Explanation of what it's waiting on
Done Issues that have been completed this sprint. Y Closed due to either being complete or deemed a duplicate, out of scope, etc.
Initiative N