☀️ The Daily Routine: Keeping It All Running

Every practice in this handbook (scoping, the board, rituals, templates) only works if someone is paying attention to whether the system is actually running. That someone is the project lead. This page is the daily checklist for making sure the gears are turning and nothing is quietly falling apart.

If you’re not a project lead, this page is still useful. It tells you what a healthy project looks like from the outside, so you can spot when things are drifting.

Start of the day

#

Before standup, take five minutes to scan the board:

• Assignments are correct. Everyone is assigned to exactly one ticket. Nobody is assigned to something they’ve moved off of. If someone is out sick, unassign their ticket. (Encourage people to do this themselves, but verify.)
• PRs link to tickets. Every open pull request should reference its issue. If it doesn’t, the board and the code are telling two different stories.
• “Done” tickets are actually done. Glance at anything recently moved to Done. Can you stop thinking about it entirely? If not, it’s not done. (See Your Project Board is a Mirror for more on this.)
• Blocked tickets aren’t being ignored. If something has been blocked for more than a day with no visible activity toward unblocking it, ping the channel and ask why.

Keeping tickets up to date

#

When all the deliverables are complete, you should be able to close out the ticket and never think about it again. If you feel like things are missing on a ticket that’s in progress, add them or reach out to the person working on it. Be conscious when closing a ticket out: are there small details that still need to happen? Flipping beta flags, verifying on prod, updating documentation. Add those things to the acceptance criteria now, not after someone forgets.

Multiple pull requests per ticket are fine. If you have multiple PRs for a single ticket, link each PR next to its related deliverable so reviewers can trace the work.

Handling blocked tickets

#

Tickets get blocked on decisions from design/product, pull requests in other repos, or waiting for testing to complete. When a ticket gets blocked:

1. Add the “blocked” label.
2. Add a # Blocked section at the top of the ticket explaining why it’s blocked and what needs to happen to unblock it.
3. If you can, tag the person who can unblock it.

Encourage the team to do this themselves. If you notice blocked tickets without an explanation, ask for one. A blocked ticket with no context is invisible to everyone except the person who blocked it.

Reassigning tickets

#

If a ticket gets blocked or someone stops working on it to help with something else, encourage them to move it to the top of the backlog and unassign themselves. This does two things: it signals to the team that nobody is working on it, and it makes it the next thing someone picks up.

Encourage the team to always scan blocked tickets in the backlog and check if they can now be unblocked. It’s easy to gloss over them. A ticket that was blocked last week might be unblockable today because the dependency shipped, but nobody noticed.

Limit work in progress

#

No one should be assigned to more than one ticket “In Progress” at a time. If your team encourages pairing, the maximum number of in-progress tickets should be roughly team size / 2. On a team of 4, follow up if you see more than 2 tickets in progress. (See Your Project Board is a Mirror for why this matters.)

Maintain a true definition of “done”

#

A great test: ask yourself “Can we stop thinking about this entirely when this ticket is marked Done?”

If you hear the words “Yeah it’s done, but…” then deliverables are missing. “Yeah it’s done, but we haven’t tested on prod.” “Yeah it’s done, but we’re waiting on data before we can test.” If you can’t close out the ticket until something else happens, block the ticket and explain what’s needed.

Closing out tickets

#

Once a story is approved and moved to Done, take a few minutes to clean it up. Remove anything no longer relevant. Add screenshots of the finished work. Link pull requests next to their acceptance criteria items. Mark each deliverable with a ✅.

This turns the ticket into long-lived documentation. Six months from now, when someone asks “how does this feature work?” or “when did we ship that?”, a well-closed ticket is the answer.

Before Done

#

## What
Provide a way for users to switch accounts.

## Why
Most of our customers manage multiple accounts. Without a way
for our customers to switch between multiple accounts, we are losing
customers to our competition which supports this feature.

## Acceptance Criteria

- When I am logged in, I can see a logout button in the navigation bar.
- After clicking the logout button, I'm redirected to the login page
  where I can log in as another user.
- Entering the credentials for my user, I should see my new username on
  the account page.

### Developer Notes

- Check out the internal service where they implemented something
  similar.
- Please favor using an existing implementation over adding a new
  library to the codebase.
- The login button can be any color, but we all prefer for it to be red
  like other destroy actions.

After Done

#

Remove sections no longer relevant. Add screenshots so everyone can see what was built. Link pull requests for engineers who want to go deeper. Delete the Developer Notes section; whether the engineer followed the advice is irrelevant once the work is done.

If things were taken out of scope, just remove them. What you didn’t do won’t matter to your future self. What you did, what it looked like, where it happened, and why you did it will matter.

## What
Provide a way for users to switch accounts.

## Why
Most of our customers manage multiple accounts. Without a way
for our customers to switch between multiple accounts, we are losing
customers to our competition which supports this feature.

## Acceptance Criteria

- ✅ When I am logged in, I can see a logout button in the navigation
  bar. (see pull request #1234)
- ✅ After clicking the logout button, I'm redirected to the login page
  where I can log in as another user. (see pull request #1234)
- ✅ Entering the credentials for my user, I should see my new username
  on the account page. (see pull request #1332)

## Screenshots
### Logged Out Page
![loggedout.jpg](…)

### Logged In Page
![loggedin.jpg](…)