> get a lot of junk applications, but frankly, it is your job to sort through them.
But this isn't their job. Their job is to hire someone who passes the hiring bar. If they can do that without ever looking at a random resume everyone at the company is happy.
An unstated thesis of the article is that several years from now people who want to accomplish that job just won't look at resumes submitted online - whatever anyone's feelings about it.
I hear this often, but I've never met someone for whom points didn't eventually turn into a measurement of time - even using the exact process you're describing.
I think any process that's this hard to implement should be considered bad by default, barring some extraordinary proof of efficacy.
> I've never met someone for whom points didn't eventually turn into a measurement of time
The goal isn't to avoid time estimation completely, that would be crazy. People estimate how many points get delivered per sprint and sprints have fixed lengths of time. You can do the math, you're supposed to.
The process is quite easy to implement. And it does wind up with extraordinary efficacy gains on a lot of teams, that's the whole reason why it's so popular. But you do have to actually learn about it. Here:
If it works for you, then it's a good method, but in my opinion the most transparent way to avoid a false sense of precision for time estimation (as with all else) is by explicitly including error bars, rather than changing the units-of-measure.
Error bars are complicated, and who's to say how large they should be? It winds up being a lot of pointless arguing over arbitrary precision.
The Fibonnaci sequence of point values has wound up just being a lot simpler for most people, as it encapsulates both size and error, since error tends to grow proportionally with size.
I.e. nobody is arguing over whether it's 10h +/- 1h, versus 12h +/- 1h, versus 12h +/- 2h, versus 11h +/- 3h. It's all just 5 points, or else 8 points, or else 13 points. It avoids discussion over any more precision than is actually reliably meaningful.
I worked on a product that was built around planning an estimation with ranged estimates (2-4h, 1-3d, etc)
2-12d conveys a very different story than 6-8d. Are the ranges precise? Nope, but they're useful in conveying uncertainty, which is something that gets dropped in any system that collapses estimates to a single point.
That said, people tend to just collapse ranges, so I guess we all lose in the end.
In agile, 6-8d is considered totally reasonable variance, while 2-12d simply isn't permitted. If that's the level of uncertainty -- i.e. people simply can't decide on points -- you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing once you have a more accurate estimate. You would never just blindly decide to do it or not if you had no idea if it could be 2 or 12 days. That's a big benefit of the approach, to de-risk that kind of variance up front.
> you break it up into a small investigation story for this sprint, then decide for the next sprint whether it's worth doing
That's just too slow for business in my experience though. Rightly or wrongly, they want it now, not in a couple of sprints.
So what we do is we put both the investigation and the implementation in the same sprint, use the top of the range for the implementation, and re-evaluate things mid-sprint once the investigation is done.
Of course this messes up predictability and agile people don't like it, but they don't have better ideas either on how to handle it.
Not sure if we're not enough agile or too agile for scrum.
That's definitely one way of doing it! And totally valid.
I think it often depends a lot on who the stakeholders are and what their priorities are. If the particular feature is urgent then of course what you describe is common. But when the priority is to maximize the number of features you're delivering, I've found that the client often prefers to do the bounded investigation and then work on another feature that is better understood within the same sprint, then revisit the investigation results at the next meeting.
But yes -- nothing prevents you from making mid-sprint reevaluations.
If you measure how long a hundred "3-day tasks" actually take, in practice you'll find a range that is about 2-12. The variance doesn't end up getting de-risked. And it doesn't mean the 3-day estimate was a bad guess either. The error bars just tend to be about that big.
If a story-sized task takes 4x more effort than expected, something really went wrong. If it's blocked and it gets delayed then fine, but you can work on other stories in the meantime.
I'm not saying it never happens, but the whole reason for the planning poker process is to surface the things that might turn a 3 point story into a 13 point story, with everyone around the table trying to imagine what could go wrong.
You should not be getting 2-12 variance, unless it's a brand-new team working on a brand new project that is learning how to do everything for the first time. I can't count how many sprint meetings I've been in. That level of variance is not normal for the sizes of stories that fit into sprints.
Try systematically collecting some fine grained data comparing your team's initial time estimates against actual working time spent on each ticket. See what distribution you end up with.
Make sure you account for how often someone comes back from working on a 3-point story and says "actually, after getting started on this it turned out to be four 3-point tasks rather than one, so I'm creating new tickets." Or "my first crack at solving this didn't work out, so I'm going to try another approach."
That's literally what retrospectives are for. You do them at the end of every sprint.
Granted, they're point estimates not time estimates, but it's the same idea -- what was our velocity this sprint, what were the tickets that seemed easier than expected, what were the ones that seemed harder, how can we learn from this to be more accurate going forwards, and/or how do we improve our processes?
Your tone suggests you think you've found some flaw. You don't seem to realize this is explicitly part of sprints.
I'm describing my experiences with variances based on many, many, many sprints.
I think it really depends on how teams use their estimates. If you're locking in an estimate and have to stick with it for a week or a month, you're right, that's terrible.
If you don't strictly work on a Sprint schedule, then I think it's reasonable to have high variance estimates, then as soon as you learn more, you update the estimate.
I've seen lots of different teams do lots of different things. If they work for you and you're shipping with reliable results then that's excellent.
Having implemented it myself, I agree it is easy to implement. My argument is that it is overly difficult to maintain. My experience is that incentives to corrupt the point system are too high for organizations to resist.
Funnily enough - I work closely with a former director of engineering at Atlassian (the company whose guide you cite) and he is of the opinion that pointing had become "utterly dishonest and a complete waste of time". I respect that opinion.
If you have citations on pointing being effective I'd be very interested. I consider myself reasonably up to date on SWE productivity literature and am not aware of any evidence to that point - I have yet to see it.
I guess my experiences are quite the opposite. Maintaining the process couldn't be easier. I don't even know what it means to "corrupt" points...? Or for points to become "dishonest"? I'm genuinely baffled.
I'm not aware of any citations, just like I'm not aware of any citations for most common development practices. It seems to be justified more in a practical sense -- as a team or business, you try it out, and see if it improves productivity and planning. If so, you keep it. I've worked at several places that adopted it, to huge success, solving a number of problems. I've never once seen a place choose to stop it, or find something that worked better. If you have a citation that there is something that works better than points estimation, then please share!
It's just wisdom of the crowds, or two heads are better than one. Involving more people in making estimates, avoiding false precision, and surfacing disagreement -- how is that not going to result in higher-quality estimates?
By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.
Stepping back - my experience is that points are solving a problem good organizations don't have.
The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers. Stakeholders understand the timeline and scope to be an evolving conversation that we iterate on week-by-week. Our rough estimates are enough to see when the project is truly off-track and we can have a discussion about timelines and resourcing.
I just don't see what points do for me other than attempt to "measure velocity". In principle there's a metric that's useful for upper management, but the moment they treat it as a target engineers juice their numbers.
> By "dishonest" I'm saying they become measurements of time, which is what we were trying to avoid.
On the one hand, they simply can't. They're a measurement of effort, and a junior dev will take more time to finish a story than a senior dev will. On the other hand, at the sprint velocity level, yes of course they're supposed to be equivalent to time, in the sense that they're what the team expects to be able to accomplish in the length of a sprint. That's not dishonest, that's the purpose.
> The practice I see work well is that a senior person comes up with a high level plan fror a project with confidence intervals on timeline and quality and has it sanity checked by peers... I just don't see what points do for me other than attempt to "measure velocity".
Right, so what happens with what you describe is that you're skipping the "wisdom of the crowds" part, estimation is done too quickly and not in enough depth, and you wind up significantly underestimating, and management keeps pushing the senior person to reduce they're estimates because there's no process behind them, and planning suffers because you're trying to order the backlog based on wishful thinking rather than good information.
What points estimation does is provide a process that aims to increase accuracy which can be used for better planning, in order to deliver the highest-priority features faster, and not waste time on longer features that go off track where nobody notices for weeks. Management can say, "can't they do it faster?", and you can explain, "we have a process for estimation and this is it." It's not any single employee's opinion, it's a process. This is huge.
> but the moment they treat it as a target engineers juice their numbers.
How? Management doesn't care about points delivered, they care about features delivered. There's nothing to "juice". Points are internal to a team, and used with stakeholders to measure the expected relative size of tasks, so tasks can be reprioritized. I've never seen sprint velocity turn into some kind of management target, it doesn't even make sense. I mean, I'm sure there's some dumb management out there that's tried it. But what you're describing isn't my experience even remotely.
> But in my experience, your manager is expecting you to do all of your assigned role (e.g. write code), but then also do a bunch of stuff on top -- e.g. leading and taking ownership of new initiatives that is extra work.
Aside from AWS, who's famously bad at this, my experience is that this is usually because people want a faster career push.
Imagine Jim, 8 years into his career. Jim is pretty good and his work takes him 30-40 hours a week. If he worked another 5 years in the same role it'd probably drop to 20 and be chill.
Jim wants to get promoted. If he waited the 5 years he could do it working 40 hours a week. But he wants it now, and since he's not as good as he will be he needs to work 60. What does Jim do? He works the 60.
There's nothing wrong with this choice, I made it, I'm happy with my choice. I might make it again in the future, or not.
> There's nothing wrong with this choice [to work extra hours to get promoted].
But if there are limited slots for promotion, and that's generally always the case, the resulting competition among deserving engineers makes the extra hours more or less mandatory. Say that Amy is a better engineer than Jim and gets a third more done per hour. If Jim puts in 60 hours instead of the expected 40, then Amy isn't going to beat him for a slot unless she also starts working extra hours.
In the end, promotion becomes more about grinding than being effective. That's not great for company culture or retention of top talent.
That doesn't make the promotion more about grinding because the company doesn't care about how much work you get done in a set unit of time compared to other employees in the same set unit of time. The company cares about how much you get done, period.
If the only differentiating factor between Amy and Jim is quantity of work done (this is never the case in real life), most companies will prefer a Jim that works 60 hours to an Amy that works 40 if Jim is producing 5% more.
In software development, sure (maybe). Most jobs aren't software development.
The vast majority of jobs your production slows as hours increase but there isn't a tipping point where you're less productive, even after accounting for errors or rework. There's a reason CPAs don't clock out at 37.5 hours during tax season, or warehouses or service desks or any number of things other than the specific thing most of us do often work more than 40 hours a week, especially when actively working to get a promotion.
> that got along well with leadership in a fast growing company
I may be reading too much into your post but I'll say that this sentiment is a common pattern I see in many competent senior folks who think they deserve promotions into roles above senior. Getting along with leadership is a huge asset for for this type of leadership role. It means that you stay aligned and push in the same direction together.
If you're not going to get along well with your leadership you need to be much much better than everyone around you - which is a significantly higher bar to clear. And getting along well is a skill. It's usually not the skill people want to learn but it's hugely valuable to be able to be chummy with a difficult exec.
> This has always struck me as a pretty juicy deal going for the corporation.
It's a good deal if you deserve the promo. Giving someone the opportunity to take on projects at the next level and having them not deliver can be enormously expensive. The higher the level, the more expensive it is.
> I hate leetcode and that keeps me away from most of the job opportunities
Odds are that until you can get past this mindset, you will hit a similar wall in every career, it will just be less obvious to you that you're hitting it.
Success at most careers means a lot of tedious grinding out basic skills. If you're lucky you like the grinding, but that's rare.
And here's the important part - getting better at this stuff makes the job more fun, humans really like the feeling of mastery. My first 4 years in SWE were miserable because I had no CS background. But I ground really hard on textbooks and leetcode, every minute of which was uncomfortable, and now my career is awesome!
Maybe SWE isn't for you, but whatever you do, commit to the work.
Maybe I’m not good at the basics, but as an ostensibly quite successful engineer, I have rarely had to do “the basics” at work, and I don’t see how leetcoding would improve my actual performance.
Leetcoding is basically testing how well you can cobble together solutions out of a decently large bag of tools. You run into other tools you have to cobble together as part of actual work, but you never have to memorize those particular tools.
So leetcoding becomes memorizing an arbitrary feeling set of tools that you never actually have to use in practice just in order to prove that you can cobble together solutions on the fly using the tools.
Certain personality types bristle at being told to memorize a large set of things for no practical reason. It feels subservient to do so.
Now if what you are really saying is that forcing yourself to feel subservient is required in a lot of careers in order to succeed, then yes totally :)
> You run into other tools you have to cobble together as part of actual work, but you never have to memorize those particular tools
The statement I like to use as an analogy to this one is:
"I don't need to know how to add or multiply numbers, calculators can do it"
This is true in a certain sense, but if you are numerate you know that speed with numbers allows you to do all kinds of quick checks that less numerate peers cannot. It's my experience that colleagues who don't get good at leetcode style problems don't actually understand the skills they've left on the table.
Yeah. For all the excesses of the current AI craze there's a lot of real meat to it that will obviously survive the hype cycle.
User education, for example, can be done in ways that don't even feel like gen AI in ways that can drastically improve activation e.g. recommendation to use feature X based on activity Y, tailored to their use case.
If you won't even lean into things like this you're just leaving yourself behind.
>here's a lot of real meat to it that will obviously survive the hype cycle.
Okay. When the hype cycle dies we can re-evaluate. Stances aren't set in stone.
>If you won't even lean into things like this
I'm sure Andy knows what kind of business was in his clients and used that to inform his acceptance/rejection of projects. It mentions web marketing so it doesn't seem like much edutech crossed ways here.
Standards come from a mixture of culture and attention. The reason SF pizza is so much worse than NY pizza is that SF does not have culture of high quality pizza (I say this as an SF native). Conversely we have higher standards for Sourdough. Seoul has higher standards for Kimchi, you get the idea.
Everywhere is like this to some extent - no people can be an expert in all things.
Quite a few of AWS's more mature customers (including my company) were aware within 15 minutes of the incident that Dynamo was failing and hypothesized that it'd taken other services. Hopefully AWS engineers were at least fast.
75 minutes to make a decision about how to message that outage is not particularly slow though, and my guess is that this is where most of the latency actually came from.
But this isn't their job. Their job is to hire someone who passes the hiring bar. If they can do that without ever looking at a random resume everyone at the company is happy.
An unstated thesis of the article is that several years from now people who want to accomplish that job just won't look at resumes submitted online - whatever anyone's feelings about it.