Monday 3-2-1 – Story points, measuring tech debt, tech requirements in job posts 💡
Monday 3-2-1 – Story points, measuring tech debt, tech requirements in job posts 💡
Edition #5
Hey, Luca here 👋 welcome to the Monday 3-2-1 ✨
Every Monday I send an email like this with 3 short ideas about:
🎽 Engineering Management
🔨 Technical Strategy
🎒 Hiring & Onboarding
I also send an original long-form article every Thursday, like the last one:
Before we jump into this week’s ideas, I want to let you know that I am working on a survey about "The State of Engineering Careers”.
The goal of the survey is to better understand how engineers and managers think about their careers, in these uncertain times. How they want to grow; how they choose companies; what they care about the most.
I do this for two main reasons:
It is highly relevant to my job — I want to keep writing about things that matter to people.
I believe this is an important topic — so I will create a detailed write-up + commentary on the survey results.
You can find the survey below — it would be fantastic if you were able to answer it (it should take ~5 mins).
1) 🎽 The 6-step process to assign story points
Since story points look arbitrary, many people struggle to assign them.
Here is my own process to get started, in 6 steps 👇
🐜 Start small — If you are starting from scratch, take a story that looks smallish and assign 2 points to it.
⚖️ Compare — measure other stories by comparing them to similar sized ones (or to the initial one). Don’t bother to be precise, just say "this looks twice as complex", or "this looks similar".
⚡ Be fast — do not spend more than a few minutes to size a story. Spending more than that brings diminishing returns.
📈 Use an exponential scale — (1, 2, 4, 8, 16), because relative sizing works better, and you don't really need more precision. In alternative, you can use Fibonacci's (1, 2, 3, 5, 8, 13)
🗒️ Keep stories small — if you have to go over 16, just assign a provisional "Epic" to it, and split it into multiple stories later. As a rule of thumb, you should be able to deliver any story within an iteration (e.g. two-weeks cycle).
🤝 Involve your team — if you have a small team (<10 devs), involve everyone in sizing stories (e.g. with planning poker). Otherwise, involve a few team representatives.
More on estimating projects:
2) 🔨 Assess tech debt with the Riot scale
When it comes to assessing tech debt initiatives, I am a fan of the system used by Riot.
They use three main metrics:
💣 Impact — business metrics impacted by the debt, or the value you unlock by repaying it. Crucial for the ROI equation.
💸 Fix Cost — a rough estimate based on some feasible solution. For the sake of prioritization, there is no need for it to be accurate. Simple t-shirt sizing (e.g. S, M, L, XL) is fine.
🦠 Contagion — this answers the question: “if this debt is allowed to continue to exist, how much will it spread?”. It’s a great angle because, in this regard, not all debt is created equal.
The contagion metric is particularly powerful because it informs on how impact and cost change over time. Bill Clark, former EM for League of Legends, explains this well:
If a piece of tech debt is well-contained, the cost to fix it later compared to now is basically identical. You can weigh how much impact it has today when determining when a fix makes sense.
If, on the other hand, a piece of tech debt is highly contagious, it will steadily become harder and harder to fix. What’s particularly gross about contagious tech debt is that its impact tends to increase as more and more systems become infected by the technical compromise at its core.
More on technical debt:
3) 🎒 Keep tech requirements loose in job posts
I believe tech requirements in most job posts today are too prescriptive. I prefer to keep them loose, for two reasons:
Brilliant people in tech come from various backgrounds you can't really anticipate. It doesn’t make sense to — e.g. — enforce a degree among requirements.
Brilliant people learn what they don't know faster than most of us realize.
The best approach is just to describe our stack, architecture and challenges, and allow people to apply even if they don't match everything.
As an example, I love these bits from this Stripe job post 👇
More on writing job posts:
And that’s it for today — I wish you a great week! 🚀 If you liked the article, consider doing any of these:
1) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
2) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. That also gives you access to the community and the curated library.
p.s. 30-days money-back guarantee, no questions asked!