Magic Estimation as an alternative to Planning Poker

I’ve always had a beef with planning poker. Story points are definitely a huge leap over the old man hours, but when you estimate them via planning poker, I’ve noticed a bunch of things:

  1. It takes way too long! Teams spend hours refining a backlog. It’s just crazy to spend that much time in a meeting.
  2. A lot of the time, people clump around Story Point 3. [You can investigate this yourself: just plot a distribution curve of amount of stories / story point]. I think it’s because 3 is a “safe bet”. You are almost always able to justify a 3: “Oh I thought he was new to the story, and didn’t have experience in it.” or “I’m sorry, I didn’t think of that.” It promotes laziness instead of actual thought.
  3. And people think of story points as absolute sizing after a while, even if your team is good and has blessed stories to refer to.
From the article: Magic Estimation is as simple as this!

So that’s why this article on Magic Estimation resonated. It seems to solve a lot of these problems, and I love it when a team does comparative estimation.

Daily Checkins: A tool for Async Work

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:


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

- [ ] 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


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:

- [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.


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)

Managing Engineers: Assorted Tips

This is the last in a series of articles about engineering management, the first one was about valuing people, the second about business value, and the third about coding in the trenches, and earning the respect of the team. This last article is a set of assorted tips about managing people, and building a great team and running it sustainably.

Hire for and Value Performance

Building a great team starts from step 1: hiring the best folks. Hire for and value performance, not “hours on the desk”, “desire to learn” or loyalty. Performance and commitment, professional behaviour and the ability to deliver value are what should matter for you. This is not to say you have to be an automaton and willy-nilly fire or hire based just on this metric, but at the end of the day, performance and delivery should drive these decisions. Use compassionate candor to communicate, and make sure that your hires align to your company values. A good hire should either be a hell yeah, or a no.

Autonomy, Mastery, and Purpose

Daniel Pink’s Drive should be required reading for anybody who wants to manage people, but a few people mistake autonomy for letting engineers do anything that they want. Cultivating good drive is about setting clear boundaries, and very clear expectations, and teaching people that the why of what they do is as important as the how:

  • Make sure that your engineers understand the why (business context) and the what (the specifics of the requirement) for a story really clearly. Why are we doing this? What is the customer need? And what is it exactly that we’re doing? If necessary, spend time with them to collaboratively shape some of the details.
  • Make sure that the success criteria for story delivery are extremely clear. What is the process through which an engineer gets a story to done? Maybe it’s PR reviews, maybe it includes some automation tests. Make sure that this is not a surprise to a new engineer.
  • For beginning engineers, make sure that they understand how to solve the problem. Most new folks are stuck trying to figure out the how: teach them that learning how to get themselves unstuck is also an important lesson in autonomy.
  • Then, leave the rest to the engineer. The trick here is to get involved when they need help, and to give folks a lot of space when they don’t.

I also think Drive is a rediscovery of a universal truth about what motivates people, and there are deeper understandings of this concept out there. Ikigai for e.g. is at once both simpler, and more comprehensive.

Valuable Books

This last section is about books I’ve read that has shaped my thinking around engineering management. The best way to read these books, especially if you are a new engineering manager is to not read them cover to cover. Skim through them, find a section that is interesting, and dig deep. And if you are struggling with a difficult scenario at work, come back to these books and see if you can learn more lessons.

  1. Julie Zhuo’s Making of a Manager is probably the most wisdom/page of an engineering management book I’ve read. It’s probably the best book for a new engineering manager, and one that I’ve recommended many times over the last year.
  2. Camille Fournier’s The Manager’s Path is also common-sense advice, but it’s a bit more geared to somebody who’s been on the engineering-management path for a few years.
  3. Basecamp’s Shape Up is an opinionated way to plan and manage your work. It’s not something you can implement by yourself unless you have top-management support, but the lessons it teaches are still valuable. All of Basecamp’s books are good reading, and offer a view of an alternative way of working that just might suck you in 🙂
  4. I’ve already mentioned Daniel Pink’s Drive, but there’s no harm in a further plug.
  5. The Goal is a book that has long been required reading for all MBAs. The Pheonix Project is its equivalent for engineering management: how an agile philosophy and simple truths around keeping work-in-progress low and ensuring slack can turn around a business. It’s a bit of an utopian read, and it’s definitely a caricature, but it’s a great intro to agile and how it can deliver value.

So that’s it! Took a month to write these series of articles! If you found it useful, I would really appreciate a comment or a tweet. Thanks for following along!

A Few Thoughts on Managing Engineers

What follows is some really common-sense advice on how to manage engineers. [A lot of it should apply to managing creative people in general, but I don’t really have any experience managing non-engineers].

And because I’ve been thinking about it for a while now, there’s quite a lot to talk about, so it’s in 4 parts. This is Part 1.

Your #1 responsibility is your people.

Make sure that they are happy and productive.

I think if you only take one thing away from this writeup, it should be this: engineering (programming, designing systems, UX, system architecture) is a creative profession, and requires time, dedication, and nurturing to do it right. Your job as a manager is to make sure that your people are on a clear maker’s schedule [2], with as little interruption as possible.

How do you make this happen? Here are two things that I’ve found works well:

  1. Keep meetings to a minimum. Promote asynchronous work. The cost of an interruption, and switching attention from one task to an urgent another is probably minimal (& expected) when you are a manager. But if it happens too many times to your creative engineering team, it is a recipe for disaster. So your job is twofold:
    1. Make a team that can function with minimal meetings. Consider replacing stand-ups with daily checkins. When you do have meetings, have them over a shared document so that decisions are recorded instantly, and everybody has visibility into how a conversation is moving & structured, and what the next steps are.
    2. Step in & protect your team when some VP absolutely wants a team member’s attention for something critical.
  2. Have regular twice a month 1-on-1s with your team members. [Of at least 20 minutes, and not more than 40 minutes long.] Valuing your team also means really listening to them. This means scheduling regular checkins with your team members where your only job is to listen to understand. This is probably one of the most important things you’ll do as an engineering manager, and it’s crucial that you do not skip this cadence step:
    1. You’ll find that the best ideas come from your team. They are the ones who are on the ground every day, facing and solving technical challenges.
    2. You have to create a safe space for them to open up and talk to you about their problems. The best way I’ve found to do this it to make sure they know the conversation is confidential and wouldn’t affect performance evaluations, and that it’s their meeting: they set the agenda, and your job is to listen.
    3. At times you’ll find that some folks really have nothing to talk about. Maybe it’s a dull week, or maybe they have had a really good month, and have no concerns. Fill in the blanks at that point by giving unsolicited, structured, actionable feedback. Talk to them about how they want their career to proceed. Talk to them about your experiences when you were at similar roles, and how you think they can improve in their role.

Well that’s it for this instalment! Next week, I’ll write about being committed to Value Delivery, your #2 responsibility.