Daily Routine of the project lead
Start of the Day Routine
- Make sure tickets are assigned to the right people and no one is assigned to more than one thing.
- Unassign tickets that people have moved off of or for folks out sick (encourage people to do this themselves)
- Ensure pull requests are assigned to the people working on them
- Ensure pull requests are linking to their respective GitHub issues
- Look at recently "done" tickets to ensure they are actually done (see
"Maintaining a true definition of "Done"below). - Make sure there's no "blocked" tickets are being ignored (sometimes helpful to just ping the channel and ask why a ticket is still blocked)
Keeping tickets up to date
When all the deliverables are complete, we should be able to close out this task and never have to think about this ticket again. If you feel like things are missing on a ticket that is in progress, add them or reach out to the people working on the ticket and ask. Be conscious when closing a ticket out if there’s any small details that still need to happen before the ticket can truly be closed out. This could be things like flipping beta flags, verifying on prod, updating documentation, etc. Add those things to the deliverables.
Multiple pull requests per ticket are fine. If you have multiple PR's for a single ticket, then it can be handy to link each PR next to the related deliverable.
Using Blocked
Tickets will get blocked on decisions from design/product, pull
request's in other repos, or waiting for testing to complete. If a
ticket gets blocked, add the "blocked" label, and update the ticket with
a # Blocked section at the top explaining why the ticket is blocked.
Encourage the team to do this if you notice tickets missing this info.
Reassigning tickets
If a ticket gets blocked or someone stops working on it to help out with something else, then encourage them to move it to the top of the backlog and unassign themselves. This will help everyone understand that they’re not working on this and that people should pick this up first if they’re looking for new tickets to work on. Encourage the team to always look at blocked tickets in the backlog and see if they can now be unblocked. It's easy for people to gloss over blocked tickets.
Limit the Number of "In Progress" Tickets
No one should be assigned to more than one ticket "In Progress" at a
time. Encourage pairing, which means we should see a maximum of
team size / 2 tickets in progress. On our team of 4, I would follow up
with people if I saw more than 2 tickets in progress.
Maintain a true definition of "Done"
A great test is to 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 we might be missing additional deliverables on the ticket. Things like "Yeah it's done, but we haven't tested on prod", or "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 is done, then block the ticket and say something along the lines of "Waiting on ticket XYZ to be complete before we can do final testing and close this out."
Closing out tickets
Once a story has been approved and moved to Done. I suggest updating the ticket to capture what was done and remove anything no longer relevant. By doing this, you can use the story itself as long-lived documentation.
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
I remove any sections no longer relevant. I add screenshots, so everyone can see what was built, and that we did check it's working. I've added links to pull requests for the engineers to go deeper. Lastly I removed the Developer Notes section as it no longer is relevant.
If there are things that were taken out of scope, feel free to just remove them. Saying 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
### Logged In Page
