Hello, and welcome to a new edition of Expander. I’m Abhishek, and each week I share practical ideas on doing product, measuring what matters, working with people, and growing a business. Send me your questions and in return, I’ll humbly offer BS-free actionable advice. 🤜🤛
To receive this newsletter in your inbox weekly, consider subscribing. 👇
Today, let’s talk about product development, or in other words, getting shit done. Here’s a straightforward question: when was the last time you correctly estimated the amount of work to be done (in a sprint) in advance? Here’s another one: when was the last time work didn’t expand mid-sprint (or any other equivalent of a work cycle)?
Unless you are an omniscient being, 99% of your work estimates are way off! Interestingly, you aren’t the only one. Since none of us can see the future, we all suffer from the same problem sprint after sprint.
The reason for this never-ending mishap is simply this: we are bad at estimates! And the worst part is that there’s no possible way to get better any time soon since there’s always some level of uncertainty involved in the nature of our work. Something always has to be “figured out” or “looked into” before we can confidently reckon how long it’ll take.
It’s never a clear path from point A to point B. There’s a dense forest in-between, and unless we get into the forest, we cannot really know how dense it is and how long it’s gonna take for us to cross it.
So, what are the consequences of poor estimates? As time passes, work increases, and the release deadlines get pushed. Tell me if this isn’t the case in your company, and I’ll personally pay you a visit and tell you that you dunno just how lucky you are. Why? Because deadlines should never get pushed. Period!
You see, pushing the deadline always sends a wrong signal to the team. If the deadlines can be pushed now, they can be pushed later as well; and they do get pushed. Any team with fluid deadlines plays catch-up all the time. Simply because this sprint’s pushed deadline puts undue pressure in the next sprint.
Trust me, there’s no boss in the world who is benevolent enough to ask the team to take up less work this sprint since they didn’t meet the deadline last sprint. The actual expectation is to speed up work this sprint, i.e., do more work in less time, and still meet the deadline. Alas, this is designed only to fail! The deadline gets missed again, and the cycle continues. The work cycle becomes a cycle of failure. It’s an ugly practice, and unfortunately most companies follow it regularly.
Now, if it isn’t clear already, what I’m trying to say is this: companies should never push deadlines. Sprint deadlines should always be fixed.
Now, that doesn’t mean deadlines should remain the same while work balloons as the sprint progresses. Because that’s not work, that’s hell! Even if this works for a while, it won’t work forever. Eventually, the team will start dreading deadlines. This is one of the common causes of attrition.
Whenever the team complains about too much work, 9 out of 10 times, bad estimate and fixed deadlines is the reason. If it’s in your power, drop everything and fix this. Otherwise, share this post with whoever is in power. They should drop everything and fix this. Otherwise, don’t be surprised when the team starts resigning.
Fixed deadlines is only half the solution. The other half is fluid scope (or work/stories/features/insert-new-buzz-word).
Here’s the immutable truth: work always expands with time. It isn’t gonna be any different this time, so there’s no point fighting it. We should embrace it instead.
You see, the first part of any work (i.e., going from point A to point B) is figuring out the terrain. For example, in a two-week sprint, the first week is usually spent in discovering the uncertainties and finding out the unknown unknowns. It’s only after the team has gotten a fair idea about the terrain, they’ll be able to budget the actual scope of the project.
This is where we measure things backwards. Here the question isn’t, “How long will it take to get this done?” Here the question is, “How much of this can be done in the given time?” This question is pretty easy to answer once we’ve gotten a fair idea about the terrain. This is also where we start pruning the original scope of the project.
In other words, instead of putting endless effort into shipping every detail, companies should focus on putting lots of effort into separating the “must haves” (what really matters) from the “good to haves” (what sort of matters) from the “luxuries” (what doesn’t matter at all). For example, a fancy transition animation would be the first one to go when there’s a time crunch.
Every project definition has some extra fluff that can be cut down. And every big must-have can be broken down into smaller pieces and each piece can be judged individually objectively. Ideally, a small piece shouldn’t take more than 2 days to complete (after the unknown unknowns are factored in, and all uncertainties removed).
If companies don’t do this — if they don’t cut down fluff and break down projects — even small projects will balloon into large projects. And if they are struggling to break the scope of a project down into tiny chunks, they aren’t thinking hard enough.
So, if we combine the two rules: a company should have fluid scope and fixed deadline.They should always start the sprint with a ballpark estimate, but with an understanding that this will change somewhere mid-sprint. Then based on the new understanding, a revised scope should be set. Who takes this call, about what should remain and what should go? Ideally, the team working on the project, and not the manager. The team that’s doing the work should have full control over it.
Shipping is the priority for any company, not perfectionism. That’s the only logic behind this iron rule, and companies often forget that. When a team is trying to fix both the scope and the deadline they may think they are thriving for perfection, but they are only creating dread, overwork, and burnout.
Companies should actively work on abandoning perfection if they wish to get more done in less work. Projects don’t have to be perfect. If the team can ship 80% of the definition with 20% of effort, then pushing to make it 100% is nonsensical. Any fool would know that this has diminishing returns.
Remember: an okay feature will any day take precedence over a perfect feature if it can ship in time — not faster or slower, but in time. Fluid Scope Fixed Deadline — use this law as a razor to cut all the fluff from the scope of a project.
Talk to Me
Do you agree with what I said, or do you think otherwise? Send me counters, comments, questions, and other ways to get more done with less effort. 🙌
Until next week,