One of the tools that I’ve used regularly both when working in teams and managing them is regular daily checkins. It’s one of the few things I’m very particular about, and most teams I’m managing think I’m a bit mental about it before giving in, trying it out, and then more often than not, falling in love with it.

So what are Daily Checkins? I started using from my first job in Slideshare, where we used Basecamp and that had this feature built right in. It’s pretty simple to explain, but it takes everybody a few weeks to get it right. Checkins are a pair of messages you post to your team communication tool twice every day: once when you begin work (the checkin), and once when you finish your day (the checkout). For this reason, it’s also been called Checkin/Checkout by a lot of teams I’ve introduced this to.

In the early days of my daily checkins, I used to be pretty lackadaisical about what I type in: it was just prose, often directed as an answer to a question such as: “What are you going to do today?” or “What did you do today?” I soon realised however, that checkins serve two purposes:

1. It’s a planning tool for you to establish a daily cadence of work^[1].
2. It’s a reporting tool for your managing and your team members to rally around you when you need help.
   1. Notice: I said team members, so it’s public communication, and not intended to be a replacement for a personal 1-on-1 with your team.

And if it has to serve these two purposes well, it needs to have some structure. What I’m about to describe is the structure that my teams have evolved it to, after quite a number of years of practice:

Checkins

An example is worth a thousand descriptions^[2], and so here’s one:

Checkin:
- [ ] Review all assigned PRs
- [ ] SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! 
- [ ] SA-826 & SA-827: Remove attack surface applicability from model & UI, make sure that I understand all requirements from the team
- [ ] SA-663: Rename SA to SAE, SAL to SA, New SAL to SAL, start writing down a clear approach here in the Jira ticket.
- [ ] Possible Blocker: Need test cases for SA-663 to move forward

Here’s a breakdown of what you see above:

1. Checkins are todo-lists in a way, so we use the simple text notation - [ ] for describing an open todo. (The corresponding finished task would be - [x]).
2. Each todo ideally starts with a project identifier if you have them. Here it’s a Jira ticket ID (the SA-834 bit). In more modern communication systems, I also make these hyperlinks.
3. After the project identifier, I write down a short phrase about what the work is about. This is distinct from what I’m going to do today to achieve progress in the work. As an example, if I’d written SA-834: finish up my PR here after reviewing comments, somebody reading it would have to look up SA-834 before understanding what it is that I’m talking about. Instead, I’m explicit and write down both what the work is about and what I want to get accomplished today: SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! This is a very important distinction: Checkins have to be skimmable!
4. Note that I also have daily routines that I write first before any of this. At most of our teams, we start our day by reviewing PRs (so that we unblock others), and that’s my first Review all assigned PRs bit.
5. I also make it explicit when I have blockers with Possible Blocker: in them, and team members, or my manager can come in and help.

That’s it! A regular cadence of doing this every day in your communication or project management tool would mean that everybody in your team is now aware of what your daily objectives are, and if you are blocked anywhere!

Checkins however, are incomplete without Checkouts

Checkouts

So I used to have just checkins on most days until I realised that something was missing. When team members began checking in every day, I realised that there were holes I was missing, the narrative of work between days was somehow fragmented because while folks would write down a lot of objectives for the day, they most often wouldn’t be able to achieve all of them. They—and I, as their manager—was missing this critical piece of feedback. So Checkin/Checkouts are a pair. Here’s how a checkout for the checkin before would look like:

Checkout:
- [x] Review all assigned PRs → Done, merged 3, thanks all for the review! 
- [ ] SA-834: Make reports work with SAL, finish up my PR here after reviewing comments! → PR #325 raised
- [ ] SA-826 & SA-827: Remove attack surface applicability from model & UI, make sure that I understand all requirements from the team → WIP in feature/SA-826-remove-attack-surface-applicability-from-SAFE-scorin g-model
- [ ] SA-663: Rename SA to SAE, SAL to SA, New SAL to SAL, start writing down a clear approach here in the Jira ticket. → Got stuck with meetings today, tomorrow!
- [x] Finished some unexpected feature reviews that came in today from the Product team.
- [ ] Blockers: Need test cases for SA-663 to move forward → Still couldn't get this done today as X was busy, I really need some help here!
- [ ] PR: Reviewed: 2, Created: 1, Merged: 3, Pending: 1

Here’s a breakdown:

1. As you can see, Checkouts are exactly like Checkins except they have additional information. For one, they check off completed tasks with a - [x].
2. Then, they suffix information about task progress. For e.g. PR #325 raised is a clear indication that I’ve made some progress with this task. This can also be negative progress however, like this one: Got stuck with meetings today, tomorrow! I generally separate out the checkout information with the → separator, but you can use anything really. I’ve seen my team members using a more indented bullet point, or even other formatting. The only rule is that is should be easy in Checkouts to make out your progress (or lack of it).
3. I make my blocker explicit as in my Checkin, this seems to have gotten worse today, and is a clear call for help: Still couldn't get this done today as X was busy, I really need some help here!
4. And it’s also possible to have more items in your Checkout (but never less) than your Checkin: [x] Finished some unexpected feature reviews that came in today from the Product team.

Details

It’s a bit of a finicky tool to explain, but team members soon make it their own. One of my delights in managing teams over the last few years has been reading their detailed checkouts. A lot of folks become good writers, entertaining me (& others in the team) with their witty checkouts. We celebrate success together, and share frustrations. Sometimes a small aside in a checkout (we really should do something about this!) becomes a trigger that brings the whole team together to build better tools.

I would love it if you’d try it out and tell me about your experiences! 🙂

---

^[1] As a planning it’s wonderful as it lets you break down work to the smallest unit of the day. Most teams work in sprints, but that’s often too big a unit to really plan around, especially for a young developer. With guidance (& feedback from the team, your performance and from your manager) with daily checkins, you can become really good at sprint deliverables. However: the biggest win of daily checkins is not personal planning, it’s the feedback cycle you get from the tool. There’s a great video that explains this in more detail.

^[2] This is why I’ve always hated man pages. I mean wtf. You write a dozen pages of prose but nobody can make sense of how to use your tool? tldr is a far better man than man. ^(giggle)