Story points are pointless, measure queues

Overall I tend to avoid using story points, but on the few teams I worked on who really wanted to use it, I always framed it around building shared understanding rather than a metric that is actually useful for estimating work.

There is nothing saying you can't refine work packages together in your team, while still using story points. That's actually how it's done almost everywhere. When items end up with a very high estimate there will be a push to refine it to something smaller. Something you should do but only as long as it still makes sense.

In fact the worst place i ever worked at was where we were given strict orders to break down every story until they all became 1 story point (still using story points...). Doesn't take a genius to figure out what happened next. All packages started having pointless micro-tasks with thousands of cross dependencies between them: "open the editor", "write a function" "write a unit test", "commit the code", "review the code". How am i supposed to write a unit test before the function signature has even been made? How am i supposed to iterate when finding bugs? More complex tasks still overran their estimates by factor 10, in fact even worse than before, some things just can't split, yet they still needed 1 point estimate.

Using the queue length and the impact on variability is still an interesting concept, i just don't think you should connect it with breaking down everything into single-sized items.

Eatimating effort-time vs completion time are quite different, serving different stakeholders. A story that takes 1 point of effort by anyone's pointing system could still take a week due to any number of factors (crucial collaborator gets sick, laptop crunched by a car, ransomware attack, whatever). The only really estimable aspect is how long the developer will spend on the work, not when it will be done. Air speed, not ground speed.

That said, it's not clear how queue analysis helps when you haven't spent any time saying how long you might expect each task in the queue to be, or what the dependencies are between tasks within and across teams. Given engaged team members, I've gotten very good results on predicting the pace of progress for sprints, and it all never mattered because everything needed to be shipped. About 4-6 weeks before each X was to be completed we could say with confidence that X would be ready in 4-6 weeks. Not terribly useful.

He knows exactly what story points are, he goes through them exhaustive, but strangely deriding them the whole time.

Then he concludes by purporting to invent the very practice you ALWAYS were supposed to have been doing to make story points work. You have to find a set of repeatable work to compare new stories to for reference. That's the whole game. That's his tasks "idea". That has always been part of every implementation and lesson on story points ive been exposed to.

It's a completely nonsensical article.

Story points have always been about queues and implementing Little's Law. Always.

Yes, it sucks to be on teams that just argue about points and don't work to refer to standard architectures for building blocks. That doesn't mean story points are broken, it's pointing out something else in your organization is broken.

A lot of real criticism in this comment, but props to the author for writing at least. It's more than I do as a part time internet complainer.

I had a terrible experience with them once. I was a relatively new, enthusiastic engineer on a struggling team of guys who'd been at the company a long time and were pretty burnt out. Inevitably I started getting all the "hard" stories with a lot of points, til it got to some stupid point where I was outputting about 80-90% of our team's combined story points. Management caught wind of it, didn't like it, so what they decided to do was adjust my points "downward" to be more in line with the rest of my team's output. It really irritated me, because it'd result in absurd situations where my teammates would get a "3 point" ticket that was like, just updating some field in a config file to an already-known value and checking it in somewhere, and I'd get this whole-ass project wrapped in a single ticket and they'd give me the same amount of points for it. And of course this was tied in to performance reviews, adding to how annoying it was.

Another super irritating thing that would happen is I'd be asked to estimate complexity on some super vaguely defined ticket describing some problem that would take a lot of detective work to even figure out how to solve, so how am I supposed to give an accurate estimate of complexity? If I knew that much, I'd already have probably fixed whatever the issue was.

Since we were tracking the actual time things took as well, our estimates got better over time. The team would help to keep others honest. For example, writing documentation always took at least 3x longer than anyone expected, so we’d alway make people add more time to those stories.

Once we had reasonably accurate time estimates, there was also a feature for available hours. If someone was on vacation, we’d subtract those hours while planning the sprint. It was then easy to see who was over committed, balance the work, and to make sure we were being realistic.

We worked like this for about 2 years. It was probably the best 2 years I had in the job. We got a lot done, we were being strategic about our work rather than reactive, and while we would push to get things wrapped for the end of the sprint and the demo, it never involved all nighters or heroics. We pushed because people on the team wanted to do more and go faster, not because of pressure from the outside. I noticed people got more down when they tried to do less, so I’d often push back on people trying to overload the sprint. If they finished everything, we could always add more. Outside the team, our VP told us we were 3+ months ahead of everyone and if I wanted to go hang out in a cafe in Europe for a few months, go.

This is all a distant memory now. So many lessons learned, but they all fall on deaf ears in the current organization.

In my experience, story points allow forecasting that's as good as any forecasting method I've ever used. And I've used pretty much every schedule forecasting method over my long career.

The author touches on many of the reasons why story points don't work. And pretty much every reason he gives is something that you are not supposed to do.

The key to getting them to work is trust, and a commitment to never use story points as metrics to measure the performance of developers. Any attempt to do so will result in gaming of the system. The tradeoff that stories provide is lack of precision in exchange for not having to spend 50% of your development cycle up front doing detailed analysis required to provide detailed estimates (which never worked anyway).

Things you must also never do:

- compare calibrated burndown factors between teams.

- Ask why the calibration factor isn't N. THe calibration factor is.

- Have stories with more than N story points (where N is 3 or 5). Decompose them.

- Introduce the least bit of stress.

- Use burndown rates to generate commitments, instead of forecasts.

- Use forecast results to justify asking developers to work overtime.

The last point, I think, is particularly interesting. The manager who was my first scrum master made the following commitment to us: you will never work overtime again. And voluntarily working overtime will be consider a bad thing, not a good thing, since it impairs predictability of the team's productivity. "I know you don't believe me", he said. But he was right. We never worked overtime again.

I work on a small professional services team customizing a couple of our products for our customers. A few times a month we get a request for an estimate to add a new feature or workflow. We do a high level customer requirements doc, discuss it as a team, the seniors from each area (design, development, qa) each provide an estimate in a range of hours. This all gets wrapped up into a final price to the customer. If they approve it, we dive into detailed design and have them sign off on the result. Then we go into development for weeks to months, qa, and then release. Our processes really haven’t changed in over 20 years. We’re constantly ranked as one of the most productive teams, and get high scores on our post-project surveys from our customers.

This is also stated in the article:

> Story points do not represent Time, yet the Velocity metric they are usually combined with defacto converts them to time, sabotaging everyone from the start by doing the thing that you can't do with a precise number and a range...adding them together.

Better yet, just don't bother with SCRUM and all it's pointless and time-consuming ceremonies and just get shit done. This is my preferred mode of working and I've been lucky to be able to work like this for the last couple of years.

I wish management types would get it through their heads that you just cannot reliably estimate most software development projects. (I said "most" -- there are of course exceptions.) You can't evaluate employee performance by looking at a burn-down chart. You can't show pretty graphs at the end of every sprint and expect that to predict the future of the project.

What you can do is set a reasonable deadline with your team, have them work toward it, and allow them to adjust your expectations on what exactly you will be getting by that deadline. Yes, establishing that deadline in the first place requires some sort of estimation, but story points, t-shirt sizes, etc. are useless for that. Everyone on the team sitting down, breaking things down into as-small-as-possible tasks, and coming up with time ranges for each task is the way to do that. Then you add up all the minimums and maximums and you have a time range for the whole project. But that range is still only a guess, and can't be taken as gospel. And it may be wild, like "somewhere between 6 weeks and 6 months", and you have to accept that.

That's it. That's the best you can do. As the project carries on, the only thing you can reasonably report on is the list of features or functionality that's been implemented so far, and the new range of the estimate based on what's remaining to do. You can also look at the completed work, and map out where in the per-task estimate range the team ended up hitting, but that still can't predict the future.

You especially can't evaluate performance based on this stuff. That requires being an involved (but not micro-manager-y) manager who knows the team and can identify when their people are shining bright, and when they are struggling (or just slacking off). It's called people management for a reason; you have to involve the humans in that process and can't evaluate them based on some made-up numbers and dodgy, hand-wavy math.

In IP routers, the goal is to keep the congested link busy. i.e., Idle time from a momentary hiccup is wasted time. You need a small buffer to do this, but piling on more data adds latency without actually doing any good.

Algorithms like CoDel realized that a lot of previous attempts to make this were noisy as heck. Minimum latency through the queue is the signal that makes sense. Everything else is misleading or gives inaccurate predictions. Why should it be any different for managing tasks for human workers?

[1] https://en.wikipedia.org/wiki/CoDel

Success with story points comes when everybody realized they are useless for anything outside of a dev cycle and when you realize that the effort into making them somewhat accurate is the valuable part.

It lost me, because we have two estimations - an overall size guess of an epic and an actual implementation estimation of an epic. Like the overall size guess is just 2-3 seniors looking at an issue and wondering if this takes days, weeks, months or years to implement.

The actual implementation discussion is however what the article is talking about. We get most or all of the team into a meeting and we talk through what needs to be done, and structure all of that into individual concrete tasks everyone can have an idea of implementing them. And then we estimate those tasks.

And this estimation in turn is communication to management. Like, we've realized that about 21 is what one of us can do in a usual monthly iteration outside of massive outages and such (we're an operational team). So if an epic turns out to require some 3 21's and 3 13's... that can easily take 6-12 months unless we put exceptional focus on it. With high focus... as a team of 4-5, that will still take 3-6 months to do.

On the other hand, something that falls into a bunch of 5's and 9's and such tends to be muddled and struggled through regardless of whatever crap happens in the team much more reliably. It needs smaller chunks of overall attention to get done.

And note that this communication is not deadlines. This is more of a bottom-up estimation of how much more or less uninterrupted engineering time it takes to do something. A 21 in our place by now means that other teams have to explicitly make room for the assigned person to have enough headspace to do that. Throw two interruptions at them and that task won't happen.

It's more bin-packing than adding, tbh.

I'm not saying to estimate tasks accurately to the hour. Just rough ballparks: "I think I can do these 3 on friday". "Give me a week, it's gonna take a pile of tests to make sure we get it right". "Hmm I probably need the whole sprint for that, we don't have a clear view of the impact, it sounds like a small change but it uppends our current architecture".

These are the real discussions, the numbers are a silly abstraction on top of this and are unnecessary.

It should also be 100% expected that the estimates will be wrong. New bugs will show up, regressions will be introduced, requirements will change last minute. It should also be expected that some tasks that were supposed to get done won't be and other tasks that weren't in the planning could be snuck in. You are "Agile" are you not?

If you're not than just go back to waterfall and stop dragging the Agile Manifesto through the mud, thanks.

The entire point of the exercise is the discussion, it gives you some idea of what is likely to go well and be finished and what is a risk factor. If you're measuring "velocity" god help you.

Story point allocation can be useful to give a quick and easy 'good enough' estimation of time/effort required for a significant chunk of work (epic).

I find that this approximate approach is almost always more accurate than trying to estimate every little task.

If the project manager and engineers try to break down a project into small granular tasks with time estimates then it's almost inevitable that the effort will be underestimated because it's virtually impossible to anticipate every sub task, blocker, unforseen delay, etc (and then there's the extra time it takes to manage all these micro tasks in your PM system!).

In such situations the old project manager trick of doubling all estimates tends to provide a more accurate timeframe.

This is why story points can be more accurate: because you are estimating the effort it takes to do something relative to your previous experience of similar workloads.

So, if you avoid estimating granular tasks and keep your estimates as the approximate amount of effort relative to something you've done before, then you will end up with a more realistic timeframe. Story points can help with this mindset. Also your team will not have to waste time faffing around in Jira too much, or whatever system you use.

Making 4-5 highly paid professionals sit around in a circle with a bunch of cards trying to estimate how long/complex/??? the task is, writing it down, and doing that every two weeks, to dubious results, is exactly what one can expect out of today's businesses.

My guess is management doesn't trust that engineers aren't just fiddling around, so they hire a bunch of management-like people to watch over the drones, and show them who's in control. And how else you can show you are in control if you don't introduce magical rituals and tracking useless metrics, and make grown people participate? That way, all these meeting rooms can be occupied and the owners can feel like something important's happening and that they are getting their money's worth.

The points will inflate or deflate over the course of months, or even abruptly change with team composition or shifting to new technologies or even vague morale issues. All that is normal, it captures important facets of work, and trying to stop it from happening only creates other problems.

What matters is that somebody is looking at near-past behavior and using it to make a near-future estimate.

* If someone tries to mandate a fixed arbitrary correspondence between points and real world time, that would be a non-ideal scenario for various reasons.

It seems to be comparing two different things, 1. Points as a method for attributing difficulty to a work item, vs 2. The collaboration process of creating a task list as a method of breaking down work.

Running a team, I found pointing useful, more useful than the individual line engineers did, as we had different goals. My goal, in optimizing the team, was to go through all our work, get everyone in a room and create a relatively optimal plan for the next couple of weeks.

By going through the exercise of pointing, we often found that something one person thought was hard, another found easy. That act of estimating would reveal knowledge one person had that another didn't, that made the task easier. Without that process, the work might have been harder do do, because the easy way was never revealed. We also adhered to a 8 points is too many philosophy that meant any item that hard needed to be decomposed to simple tasks to repoint.

The "queuing" section basically implies the planning process should decompose tasks all the way to nothing but 1 point stories (or at least similarly sized work items within some variance). It's basically the same process as pointing, except not calling out some things are chunkier than others because it all comes out in the wash.

TL;DR this articles definition of queuing is basically pointing where task = 1 point items.

* When is it going to be done?

* How much is it going to cost?

You should therefore estimate in units of time because you will be held accountable for time. (And time is money.) This is straightforward if you break the work down into components of manageable size beforehand and prepare a bill of materials itemizing each component that the final product will require. Using the BOM approach means that completion progress for the system as a whole can be tracked in terms of which materials are complete and ready to go, not just a number or percentage of how complete someone thinks it is.

Now what if your team gives one set of estimates and the estimates are off? Well, what managers have found is that usually there's a pretty consistent ratio between the time a programmer estimates a certain task will take vs. the time it takes them to actually perform a task. Therefore, the correct way to go about time accounting is, for each task, the developer should give a time estimate before starting the task and record the time it actually took them to complete it when they are finished. The ratio between the two, as it stabilizes over time, will give project management increasingly good information about how long it will actually take a given developer to do a given task, based on their estimate, and enable them to calculate schedules accordingly.

Story points are usable, but they're a "Wild Ass Guess" metric, not a true metric of actual work, and treating them other than a guess is fraught with problems. A 13 point story could fall somewhere between 8 and 21.

Some stories we guessed 8, and ended up being more like 21 (because the dev had to fight unexpected politics, or the API was billed as being "easy to use" but anything but.)

All these are fine and should be fine to developers, except to management.

If your tasks aren't the same level of effort, then one task could take a week, and then next takes an hour. The author seems so sure, I'm almost sure I missed something, but unless you can reconcile how you can have 1 hour tasks and 1 week tasks and consider them the same, well... I'm just confused.

So, that puts us back at square one, for the most part. A story point may not tell you a lot, but tasks in this form often present the same problem.

It's not only because of the schizophrenic process of estimating tasks' complexity (not time) to understand how many of them can be added to a two-week time window.

In teams that focus on points:

1. you spend time giving points to tasks in a meeting with the whole team

2. to calculate how many points can be added to a sprint based on the points given in the past, without any adjust for the cases where the points allocated to a task were wrong

3. to determine the group of tasks that will be assigned to each developer

4. to finally, discuss why the number of points assigned to a sprint was not fully delivered (it's rare to find sprints where the tasks are delivered earlier; Parkinson's law explains that)

It's unlikely that any stakeholder would prioritize a team's precise task estimation over the rapid delivery of features or projects.

In this sense, a kanban process will have the same outcome with much less energy spent, and small tasks will give you the same statistical value without spending hours estimating "complexity."

The Sisiphisean job of trying to assign the correct number of tasks to a sprint is only there to comfort team members who don't want to consider the actual value of the processes they use.

With the pure queue solution, you still need to make sure the tasks are all "small". The problem of defining "small" is the same problem that makes story points so unreliable and confusing. So I suspect the kicker here is just having a group of motivated and competent people.

Then that new thing becomes the new measure, you change what you do to meet that measure, and things are screwed up again.

The author's final paragraphs describe implementing a complex process that an intelligent team has to use in a nuanced way. And somehow simultaneously declares that the original problem was story points, one single aspect of a complex process, and not the fact that there's a complex process that nobody understands or follows correctly.

You know how Toyota gets TPS to work so well? They do one thing, well, at a time, repeatedly.

Product development sucks because it's trying to do a million things once, constantly changes its mind, doesn't train its workers, and conflates designing, engineering, assembling, and operating, as one giant "thing". Then it wonders why it can't keep track of time.

All the stuff about breaking down tasks, watching a backlog queue to monitor cadence, and have regular meetings is already happening with, or without story points.

People overthink this stuff all the time. Every team should figure out what works best for them, even down to project by project. Getting shit done isn't hard to monitor. You have a bucket of well defined tasks, have sprint meetings, look for blockers and assumptions, watch work flowing through. It's not really that difficult. Whether you use story points or some other estimation tool is really just an exercise of calibration, it's not gospel. The estimation process is the important thing, discuss as a team, agree on complexity, make sure the task is bite sized etc.

In that case, you absolutely always have an impossibly long queue. The things that don't get done keep going into technical debt, which as a rule doesn't decrease. Until at some point you declare technical bankruptcy.

If you reduce this to just the queue for the current sprint, that is generally a smaller size, the queue length is determined by ... the story points.

So to manage the queue without story points, your job is to break the stories into equal-sized tasks, so that the queue size has a meaning. However, you cannot break a story up that way (this requires estimation of task complexity -- the premise of the article and our own battle tested experience is we don't know how to do that) and even if you could you run into the infinite queue as I mentioned.

> I am certified to teach it as a SAFe Practice Consultant (SPC)

:sus:

I couldn't care less about the resulting quantification. What matter is how well we communicate in the team, how helpful we are with each other, how well we can progress and keep motivation where struggle with huge hindrances paving the way. The points are not the point, but they are not pointless.

The map is not the territory. Everyone can have a different map and a different metric system if any. If at the end of the day people inhabiting the territory do it in a satisfying way, all good. It doesn't matter much what the plan on the paper might look like: it will always be a mere epiphenomenal artifact of the actual human processes at play.

The article presents the "story points" problem to be caused by an ignorant or presumptive misunderstanding of how the system works by outside parties.

I think articles like this are an interesting and necessary part of the overall project-managent discourse. However, they tend to infer that the problem of ignorance can be resolved by the management framework directly, to which I disagree.

Ignorance, regardless of project-management, has to be addressed by clear communication and boundaries.

I liked the suggestion of having a dedicated architecture team to break things down into work items.

Comment your favourite parts/highlights?

You can sugar coat it all you want and say they represent complexity, but at the end of the day(or sprint), the higher the complexity, the more time it takes to complete.

The alternative approach is to do more detailed estimates. In addition to any design work this can require time boxing a “spike” to better understand things. This approach works well for estimating but leaves the sprint uncommitted until the spikes are complete.

They do not equate to hours and cannot be boxed by management expectations.

Management can separately track actuals (hours), but that really should never concern the team.

I've checked scrum guides released in 2010 and in 2011. The word "commitment" does not appear in the pre-2011 version. And, as far as I remember, the word "forecast" replaced the word "estimate" in the 2020 edition of the scrum guide compared to the 2017 edition.

In one team, 3 points might be equivalent to 3 days work. In another it might be 1 day.

Reflect your uncertainty in your estimates using confidence intervals.

If your confidence intervals are too wide, break down the work and estimate the smaller tasks and/or spend some time doing the work necessary to narrow your confidence intervals.

Story points are just a warmup for more elaboration, not an xor decision. This article is making a single-level decision, which completely misses point of using story points. The work-effort really required will be discovered in more elaboration. Story points just give you a live or die measurement, that's it.

Queue theory only becomes a problem when (1) stories are being added to the active story queue at a furious rate; and (2) nothing gets shipped until the active story queue is emptied. I don't think think either of those things are supposed to be true in an agile process, especially the last.

It sounds suspiciously like a symptom of gamification to me (if new stories are being added by the development team). Or a broken process where field defects (which are supposed to go to the top of the queue) are so numerous that they completely overwhelm active development, which is an entirely different issue, requiring an entirely different response from management.

If story points are so wrong that it no longer fits in a sprint, it seems reasonable to split the story. In my experience, I don't think I've seen it happen more than a handful of times. How often is an initial story point estimate so wrong that it has to be revised upward to the point that it no longer fits in a sprint? If it's wrong, but still fits in a sprint, just do it. It makes me wonder whether there's gamification going on around using story points to evaluate developer performance.

(Assuming that stories are converted to tasks at the start-of-sprint meeting).

Story points are relative value as defined by the team, for the purpose of forecasting and reporting. They really can be anything the team decides, as long as it's a reliable measure. Ultimately they exist to answer"How long will this take?", which is the most dependable question from people writing the cheques.

People asking that question don't care if it's Fibonacci or hours or t-shirt sizes or anything at all.

"Is x bigger (or smaller) than x", followed by "is this more important than this" should be brain-dead easy and logical for everyone involved.

In my 10+ years I've learned that it's ultimately just that people don't want to be told what to do and/or need tribalism (an "other") to feelat balance with their environment.

There's no escape from prioritization and sizing. Throw scrum in the garbage and you'll still be doing it by another name.

I would suggest that a good manager doesn't need this communication.

A good manager will have already done the task, or something similar, to already know how quick it can be done.

If they haven't, they're probably inexperienced in the task. They were appointed because they were a "people person" but this fact has actually introduced more friction to the team (needing the story points yada yada) rather than just assigning a simple deadline from the get-go.

Once a deadline is introduced, Parkinson's Law kicks in and you get more or less efficient work depending on how aggressive the deadline is.

I'm advocating for experienced managers, not deadlines per se, since that is just 1 tool in the toolbox.

I'm also advocating against the countless asinine ways to communicate to lousy managers. Throw the points in the trash and start hiring cracked programmers as your engineering team's standard bearer.

See the company grow and have happier employees.

Why? Don't know, whole article reeks of gut feeling, which is strange as data should be available since the whole point of scrum masters is clerking things out.

The problem with a queue system is not in the averages tho, but in the exceptions: say sprint or project is late, which features give you the largest impact when moved around or canned? If the customer wants to reduce cost, how do you give visibility of feature effort? Or are we in the toxic agile version with fixed scope, cost and deadline? Because then just ditch the overhead and waterfall your way trough

OH and btw this system is not gaming resistant, people may pick the smaller task first to meet queue processing frequency, and then you'd get massive frequency drop at the end.

I hate story points, in fact I hate most automated issue trackers, generally speaking. I don't mind that there's a backlog and that features should have some details. But I'm now stuck in an org where we're doing SAFe/PI planning 6+ months ahead of where the devs will actually do the work, and designs that likely won't represent the true solution in practice among dozens of teams in a very large company.

It's kind of insane.

Similarly:

> What happens when the team has turnover? What happens a few months down the line when this work comes back up based on the points that were given previously?

Why would you ever put points on it a few months ahead of time? You do estimation in the sprint planning when it's a candidate for that sprint. There's no need to write down the reasoning for the estimation because the estimation is only relevant for the duration of that meeting (as you prioritise stories for that sprint), and maybe in the retrospective two weeks later if the estimate was way off.

I can see the argument for t-shirt sizes. The "queue" idea is the opposite, and has all the problems of point/time estimation.

> When anyone not directly involved with the project asks why it's taking longer than they thought, the answer will be spelled out in the tasks list. These changes were added on these dates, for these reasons based on this feedback from these people. There is no "your estimate was wrong" situation. There is no "re-estimating" process. There's not even an ask to approve if you can change the point value. It just happens.

Guess what? They're going to ask for dates. They're going to ask why the estimate changed, and not care about the answer because they just want to blame you for their estimates being off. And your "tasks" have just become the same time tracking that you were (rightly) scared of; you have the same problem of having to do a bunch of pointless busywork to justify that you were actually working. (Suppose a "task" is suddenly twice as complex as you thought it was; now you've got to file a second "task" with a fake description to justify why you only did 3 tasks this week when Bob did 4).

The problems the article identifies are: spending too much time and effort on estimation, estimating too far in advance (and then having the team and/or circumstances change), and treating estimates as deadlines. These are all real problems. But they're not problems with story points (indeed story points are actively helpful on the last one, since everyone has to at least pretend to admit that story points are not time estimates), and they're just as easy or difficult to solve whether you use story points or something else.

But in terms of scrum and points here's my take:

I've seen points work on some teams and not work so well on other teams. It's imperfect, but if you just accept that, you can make it work quite well.

The reason it's helpful to estimate complexity as opposed to time is that people with different experience levels would give different estimates based on their abilities. Complexity allows you to rally around a common understanding of a solution regardless of how fast one team member might be able to complete it versus another.

Does complexity have some relationship to time? Absolutely. Everybody knows this. That doesn't mean that we should be using time instead.

So how can a team estimate accurately? You will hear from some people that their estimates were wildly off or that it's impossible to estimate a project or they felt pressure to under-estimate. If your estimate is too broad, you need to do the mental work of breaking it down into smaller chunks that are easier to estimate. If you feel under pressure to ship on an unrealistic schedule, that's not a points/scrum problem. But the "it's done when it's done" is also not realistic either.

The idea that the estimate has to be 100% spot on is also not true. Again, it's imperfect and that is ok. But you'll find that the better a team knows their codebase and knows the product, the better they'll get over time at estimating. But if the work is too vague, the team should push back until they have enough information to more accurately break things down. This process makes for better software, especially when the team does it together.

Another missing aspect I see a lot is having a feedback mechanism. If you as a team are discussing why a task took longer than the estimate, or track metrics over time, you can all get together and figure out where problems on the team are. For example: maybe there are too many bugs that are hindering product work? Why? Maybe you're moving too fast vis-a-vis the expected quality bar. Some sort of feedback mechanism (e.g. retros) is crucial - the team as a whole should aim to deliver what it says it would and understand why it couldn't.

The whole point of these things is that as a team you can deliver consistently not more speedily. Consistency comes before speed. The other important thing is having a way to continually improve. You want to use each sprint as a way to measure the team so it can get better.

When I've seen teams that did this well, they were dramatically more productive than the teams that didn't do it well.

Maybe at some point in the future, we'll break the article and have a few people on the team each read it part of it for lower effort, and then synthesize their take aways.