8 ms·

Estimation isn’t for everyone

85 points by petercooper 3y ago

Bostonian 3y ago
I am a data scientist hired this year at a 30-employee company where I am the only programmer. I meet with my boss about weekly to discuss progress and what to work on. How should solo programmers "estimate"?
- JohnFen 3y ago
  It sounds like you're probably doing appropriate estimations when you meet with your boss.
freetanga 3y ago
Back in the late 80s we called that Release Management, and was fixed capacity bundling small maintenance and improvement tickets, executed in 3-4 weeks - waterfall - methodology. Funny how our discipline is stuck in a circle of perpetual re-discovering the past. Maybe we don’t deserve the title of Engineers and should be Software Artisans. Large projects were still the multi month waterfall that got so poor fame (a bit unfairly I might add) Quality of the team is the key. Methodology is secondary.
oraphalous 3y ago
Oh you want some kind of numerical estimation measure? <Rolls 1DFibonacci in his mind> It's a three. Have fun! --- Unless it's something I've actually implemented before - this is pretty much what I do these days. You can sprint plan all you like - but in my arena (front-end) there are so many things that can mess up your best laid implementation plans. So in such a scenario - I agree with the article. Just get on with it. Do a quick, rough plan and get to coding up a rough PoC that validates the approach as quickly as possible. Folks get anxious when there is implementation uncertainty. And I've learned that voicing this uncertainty just erodes their trust. If I do discover a problem with my implementation that is going to cost some extra time - then they generally have no problem with that as long as I communicate the discovery promptly along with a confident appraisal of the effectiveness of my new approach. Folks are fine with mistakes that happened in the past. They only fear the possibility of mistakes in the future.
- sverhagen 3y ago
  A three is fine. (Or a two. Whatever you want it to be.) In fact, everything is a three. (Or a two.) If it's a five, or an eight, it just needs to be broken up further, until it's a three. (Or a two. You see, I don't care.) If you don't know yet how to break it up, you need a spike. A spike is... you guessed it, a three. (Or...) My point (pun intended), the points are for discussion, not for measurement.
  - sirsinsalot 3y ago
    This is correct. There's lots of people in here complaining with all the authority of experience when in fact, they're complaining that the ruler they're using to measure a mile is too small. Throw rulers in the bin! Down with measuring all together! Engineering needs risk management, accurate estimation and prediction, cost control and all the other things SWEs tend to thumb their nose at. If you think something is crap, chances are you're using it wrong or don't understand. Sadly software is filled with "smartest person in the room" types who think if they don't understand something, then it is clearly not them at fault! Pop your ego aside and ask. People like Sverhagen actually know what the tool should be used for. Sadly software isn't building a house, assembling a car or any other engineering task with very uniform and predictable discrete components ... so we need measures that deal with the ambiguity, complexity and attempt to measure inaccuracy accurately. Estimation with something like a fib sequence is designed to abstractly encapsulate the real-world impact of a task in terms of risk, effort, unpredictability, variability and so on. Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. Sadly unsuprising that many offer no alternative, just complaints and bluster.
    - JohnFen 3y ago
      > Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. I think most software engineers know this. In my experience, the problem is that management doesn't.
  - 3y ago
senko 3y ago
I almost didn't the article because wth can NYT tell us about agile software? Some thrice-washed-down generalization for the masses, full of holes? Turns out it's from their dev blog and it's an interesting read.
hereforcomments 3y ago
I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely alone. I had no choice but to follow good practice to maintain them alone. I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go.
- rvense 3y ago
  I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira.
  - hughesjj 3y ago
    To be fair I've seen some people interpret the manifesto to mean "never document anything or take time to introspect", which leads to its own set of problems. As with everything, a purposeful balance is best imo.
  - Mailtemi 3y ago
    The people who were capable continued to program, while the incapable ones found an easier career path through Agile.
  - senko 3y ago
    The same way people went from "everyone should be equal" to Stalin. In comparison, Jira's not so bad...
    - rvense 3y ago
      Modern day salt mines would definitely have a kanban board though
4ndrewl 3y ago
Well, it's about story points rather than estimation per-se. The alleged inventor of story points says their invention was probably a mistake: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... But most people ultimately want estimates to determine whether or not a project is going to be late or over budget (often the same thing). What's worked for me is to ensure the stories are of the same sort of size (ie they mostly sort of look like they could be done in a few hours/days/week/months) - count them up and divide by remaining time. You'll then get an idea of whether you'll need to deliver 2 things a week or 50 - and you'll have a gut feel on whether that's achievable.
- cheeseface 3y ago
  This works well, if the size of the stories is small enough. When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
  - sverhagen 3y ago
    Agreed. But and then... making small stories only works well for a limited horizon. So, now your estimating only works for planning ahead a limited time. You use that to build a general confidence in having a constant stream of feature output. And the same people can then make some assumptions about future projects, based on similar projects in the past. Which works great for feature factories, less so for committing to a tight, hard deadline for a big project that exceeds the limited horizon.
    - 4ndrewl 3y ago
      Need to be sized appropriately to the project and planning exercise. Small stories for short projects, larger ones for large projects. Probably a bit of Goldilocks at play here.
    - cheeseface 3y ago
      This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.
danielvaughn 3y ago
Just before I left my last gig, I was toying with an idea similar to this. The idea was that our daily “standup” would be entirely asynchronous, prompted via a Slack bot. The bot would grab our in-progress tickets and ask us about each one in turn. For each ticket we give a “gut check”, which is how far towards completion we feel we are (expressed as a simple percentage). A core idea is that it’s not expected for the dev to be accurate in this assessment, just to be an honest guess. Over time the bot would collect and run some analysis on this data, and would then know the average velocity of the team on a per-dev or per-ticket basis. I still like the idea, even though I’ve never implemented it in practice. One glaringly obvious fault is that it can’t really account for outliers. But relying on percentiles rather than averages might alleviate some of that.
- janalsncm 3y ago
  That’s not a bad idea. Especially given that estimation datasets are extremely small, this could quickly give some better data.
- SenHeng 3y ago
  That requires that your tickets be atomic enough, meaning project management and planning is still required . Or you’ll end up on a single mega-ticket the entire time.
- sverhagen 3y ago
  Every story (or task) you're working on should be so small that if you're working on it for more than two or three subsequent daily stand-ups, alarm bells should go off. In your supportive team that means someone notices this during standup and offers to help get you unblocked.
  - Falkon1313 3y ago
    That assumes that you're blocked, not making progress every day. If a task typically involves a combination of data structuring, some business logic, and the UI for it, as well as any necessary API, integrations, migrations, and of course automated tests for all that, then it might take more than a couple days. Doesn't mean you're blocked. You say when you're blocked, the clock doesn't.
drewcoo 3y ago
So . . . article claims not just estimation (which is not agile - we all always estimate!) doesn't work, but the rest doesn't work, too. This is obvious BS. Not sure why, though . . . Because the author complains a lot but really doesn't exactly say . . .
jpswade 3y ago
Estimation, especially story points are just a tool to help you communicate and talk about the size of work. Most of the time it’s likely to average just under a 5, so you round up, as most work will fit within a week, which is the underlying “effort” you’re getting from velocity. For a team of seasoned developers you might as well make everything a one and go kanban.
baal80spam 3y ago
NYT is an expert body on software development now?
- AugustoCAS 3y ago
  I cannot say about NYT, but a lot of newspapers have amazing tech teams. The tech team at FT has an excellent reputation. Unfortunately, some tabloids also have really good tech teams, but I shall not name them because they sell toxicity.
  - sam_lowry_ 3y ago
    I once lead the tech team at a smaller news outlet. Software developers join the news and media business because there is a lot of interesting high-load work, the competition in the business is fierce, so engineering tends to be frugal and good. Journalists usually own the copyright to their writings, which by extension applies to software developers working in the same business. Unfortunately, the pay is below the market, people come, enjoy coding, beef up their resume and github profiles with open source code straight from the workplace and go.
- petercooper 3y ago
  I'd say they're well above the median tech company if there were such a measure. The NYT might be a media company, but it's one that ships constantly, at scale, and over long time periods.
juliangmp 3y ago
Gonna suggest this at my company, see y'all on the stake they'll burn me on
- gepardi 3y ago
  They might; I suggested we give everything a two, because that’s what the point value was most of the time. I added some thing along the lines of “it will take the time it will take regardless of whatever point value we assign to it.“
devjab 3y ago
I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had the honour to be selected to work as an external examiner for CS students for the past 6 or 7 years. I’ve spent most of my time in non-tech enterprise organisations, and recently working with non-tech start-ups that are transitioning into enterprise organisations. In my years in the public sector I had the fortune to both make an impact on our national strategies and work along some of the best talent in the Danish Software Industry, both from major software houses and tiny ones. I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools. This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines. I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for “how to work” intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work. I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets “agile good, waterfall bad” into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your “we don’t know what features we can finish” contract. Or that everyone basically expects your estimates and deadlines to fail. Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun. Anyway. I tend to take the “easy” road. I fairly quickly figured out management wasn’t for me. I’ll still do architecture, but I’ll never do it in a way that dictates anything by ever again, enable? Sure, but I won’t boss devs around. Mostly though, I’ll work with development and try to help teams become efficient at building software with the least project management possible. We’ll the PM people be PMs and then let them send their user stories or whatever format they want to the developers once they are deemed so ready that a fresh hire could program them in whatever way they want. Then on the programming side, we streamline as much of the process as possible so they developers won’t have to make a lot of infrastructure or coding-standards decisions, but see completely free to just work on coding. I like that, and as long as our business has enough of a need for developers, I’d encourage people to find what they like and work in that. So when the head hunters contact you, ask them what sort of processes they have, and if they say stuff you don’t like, then hang up. That way you’ll never have to do estimation again unless you chose to. At least for as long as we’re in a buyers market. Once that ends, there is always woodworking.
readonthegoapp 3y ago
tldr; agile etimation is stupid, don't do it. this was an enjoyable read/skim. it had at least one funny. my boss once asked me to track velocity with a small dev team -- we tried half-heartedly, and i had senior folks, who i knew also didn't want to be micromanaged, so i knew we'd get rid of it, and we did after a little while. "OK, i say we skip the estimates/points nonsense this week, and maybe do some work instead, yeah?" "Yeah." and that was that. got rid of most of 'agile', in fact, and got a lot faster. at least, by my estimation. zing.
serial_dev 3y ago
I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows what else (e.g occasional scrum of scrums for a feature nobody understands, across teams and domains, with around a 100 people, with breakout rooms and presentations of all the teams' "commitments"). Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. Once I wrote a script to fetch all the relevant data from Jira to figure out whether or story points give better estimates than simply counting up the stories (because of course Jira makes this as hard as possible for you to find out). I went through the channels, discussed it with different people, at every turn I added more info to the report demonstrating the pointlessness of story points, at each turn the data supported my argument stronger and stronger, across all our teams, for sprints going back years. After weeks of discussing it, we kept the story points, because "upper management wants numbers". Now, I work at a company where we keep things close to the agile manifesto, we adapt as we go, and we aren't forced to play stupid planning poker, and we have twice a week a short sync call (15 minutes). For as long as I have the choice, I'll not work for a company with Scrum and story point estimations.
- danwee 3y ago
  > Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label? Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.
  - 3y ago
regularfry 3y ago
Subtle point, possibly, but: > It’s important to note, though, that the throughput metric applies to teams. An individual does not complete a certain number of points per week. This is an important distinction, because you don’t want your developers to feel judged by the system, or to try to game it by engineering the tickets they take on. This is true, but it's not the main reason to treat the team as the unit of delivery. It's because total team delivery isn't the sum of individual delivery: to treat it like that would be to miss the incidental sideways contributions all the team members have on each others' tickets. If you're doing it right, your most capable people might have very low individual throughputs because they're lifting everyone else up.
deleted 3y ago
[deleted]
scotty79 3y ago
I think agile estimation is a good pretext to have a discussion about work where things come to attention and things get split up if they begin looking too large. Disciplined and insightful developers can have this discussions spontaneously but those are not the people those rituals are for. Points and velocity are orthogonal to this. They might give overseers the added benefit of having some estimate. But they bring along the risk that they'll be used for performance assessment which makes them useless for any estimations and horrible for assessment and bring inefficiencies inyo the discussion during estimation and planning. If points were averaged or forgotten after planning for some teams it might work better.
sethammons 3y ago
The article buried it a bit: cycle time. Reducing cycle time means more value faster. This is a good metric for driving discussions. As for points, the best system I've worked with is 1, 2, or 3 points. 1: we know exactly what to do. 2: we have an idea what to do and we feel the story should not be broken up any further. And 3: we don't know how to solve this; break it up or create a spike to study the problem to break it down or accept the unknown. Everything practically becomes a 2, and is thus in line with the article - the number of stories is pretty reliable between sprints and for projections. The advantage of 1, 2, or 3 over "no points" is that it drives conversions on if something should be broken down. The team quickly starts creating tickets that generally are 2s and pointing a story typically takes a team of 6-8 about 10 seconds. A 3 may be talked about for a minute before it is accepted or broken up as agreed to by the group.
- hinkley 3y ago
  You’ve basically got small, big, and too big. Which is pretty close to my favored model. FDD is rarely seen but it didn’t do points, it did the Law of Large Numbers. When you have 400 stories you can build trends off of them.
theelous3 3y ago
To ask a question probing at the title... who _is_ it for? Who's doing such well known repetitive tasks that they also need estimation for? Circular black hole imo.
gepardi 3y ago
I resonate with several points. I worked at a place for tickets could have a value of : 1,2,3,5 Most of the time it was a 2, with the occasional 1,3. It’s as if some devs enjoyed the time wasted on the banter if we had a fat one or a skinny two or a fat too, or skinny three. It was such a waste. At one point, I said we should just give everything a 2 because in the end it will take the amount of time that it will take. Regardless of whatever point we assign this ticket. I don’t miss that job. We spent more time grooming and planning and doing retros instead of collaborating.
Braini 3y ago
Obligatory Link to the "Estimates" song by $stdout, its great: https://www.youtube.com/watch?v=sh7A8UChBTI https://www.youtube.com/watch?v=sh7A8UChBTI

85 points by petercooper 3y ago

I am a data scientist hired this year at a 30-employee company where I am the only programmer. I meet with my boss about weekly to discuss progress and what to work on. How should solo programmers "estimate"?

JohnFen 3y ago
It sounds like you're probably doing appropriate estimations when you meet with your boss.

freetanga 3y ago

Back in the late 80s we called that Release Management, and was fixed capacity bundling small maintenance and improvement tickets, executed in 3-4 weeks - waterfall - methodology. Funny how our discipline is stuck in a circle of perpetual re-discovering the past. Maybe we don’t deserve the title of Engineers and should be Software Artisans. Large projects were still the multi month waterfall that got so poor fame (a bit unfairly I might add) Quality of the team is the key. Methodology is secondary.

oraphalous 3y ago

Oh you want some kind of numerical estimation measure? <Rolls 1DFibonacci in his mind> It's a three. Have fun! --- Unless it's something I've actually implemented before - this is pretty much what I do these days. You can sprint plan all you like - but in my arena (front-end) there are so many things that can mess up your best laid implementation plans. So in such a scenario - I agree with the article. Just get on with it. Do a quick, rough plan and get to coding up a rough PoC that validates the approach as quickly as possible. Folks get anxious when there is implementation uncertainty. And I've learned that voicing this uncertainty just erodes their trust. If I do discover a problem with my implementation that is going to cost some extra time - then they generally have no problem with that as long as I communicate the discovery promptly along with a confident appraisal of the effectiveness of my new approach. Folks are fine with mistakes that happened in the past. They only fear the possibility of mistakes in the future.

sverhagen 3y ago
A three is fine. (Or a two. Whatever you want it to be.) In fact, everything is a three. (Or a two.) If it's a five, or an eight, it just needs to be broken up further, until it's a three. (Or a two. You see, I don't care.) If you don't know yet how to break it up, you need a spike. A spike is... you guessed it, a three. (Or...) My point (pun intended), the points are for discussion, not for measurement.
- sirsinsalot 3y ago
  This is correct. There's lots of people in here complaining with all the authority of experience when in fact, they're complaining that the ruler they're using to measure a mile is too small. Throw rulers in the bin! Down with measuring all together! Engineering needs risk management, accurate estimation and prediction, cost control and all the other things SWEs tend to thumb their nose at. If you think something is crap, chances are you're using it wrong or don't understand. Sadly software is filled with "smartest person in the room" types who think if they don't understand something, then it is clearly not them at fault! Pop your ego aside and ask. People like Sverhagen actually know what the tool should be used for. Sadly software isn't building a house, assembling a car or any other engineering task with very uniform and predictable discrete components ... so we need measures that deal with the ambiguity, complexity and attempt to measure inaccuracy accurately. Estimation with something like a fib sequence is designed to abstractly encapsulate the real-world impact of a task in terms of risk, effort, unpredictability, variability and so on. Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. Sadly unsuprising that many offer no alternative, just complaints and bluster.
  - JohnFen 3y ago
    > Odd that software engineers so adept at abstract reasoning can fail to see that this estimation method (like all of them) is a lossy encapsulation of many concerns. I think most software engineers know this. In my experience, the problem is that management doesn't.
- 3y ago

senko 3y ago

I almost didn't the article because wth can NYT tell us about agile software? Some thrice-washed-down generalization for the masses, full of holes? Turns out it's from their dev blog and it's an interesting read.

hereforcomments 3y ago

I'm a self-taught developer at global market leader company. I worked on the business side for years and built quite a few internal apps end-to-end completely alone. I had no choice but to follow good practice to maintain them alone. I was quite reluctant to join the dev team, it never had a good reputation, but eventually decided to give it a go. Agile and estimations, spill overs, etc is such a pain in the ass, it feels like a pseudo-science. A lot of people spend a lot of energy on just this administration while we are way behind on many other things, like proper unit testing, good quality documentation, well established CI/CD. And everybody is focusing so much on the estimates, tickets like this was the end goal. I want to change their approach but there's a long way to go.

rvense 3y ago
I still don't understand how we went from the Manifesto's "individuals and interactions over processes and tools" to... Jira.
- hughesjj 3y ago
  To be fair I've seen some people interpret the manifesto to mean "never document anything or take time to introspect", which leads to its own set of problems. As with everything, a purposeful balance is best imo.
- Mailtemi 3y ago
  The people who were capable continued to program, while the incapable ones found an easier career path through Agile.
- senko 3y ago
  The same way people went from "everyone should be equal" to Stalin. In comparison, Jira's not so bad...
  - rvense 3y ago
    Modern day salt mines would definitely have a kanban board though

4ndrewl 3y ago

Well, it's about story points rather than estimation per-se. The alleged inventor of story points says their invention was probably a mistake: https://ronjeffries.com/articles/019-01ff/story-points/Index.html https://ronjeffries.com/articles/019-01ff/story-points/Index... But most people ultimately want estimates to determine whether or not a project is going to be late or over budget (often the same thing). What's worked for me is to ensure the stories are of the same sort of size (ie they mostly sort of look like they could be done in a few hours/days/week/months) - count them up and divide by remaining time. You'll then get an idea of whether you'll need to deliver 2 things a week or 50 - and you'll have a gut feel on whether that's achievable.

cheeseface 3y ago
This works well, if the size of the stories is small enough. When trying to get ”consistency” rather than trying to estimate better, you should aim for a smaller ”batch size” since it results in less variability.
- sverhagen 3y ago
  Agreed. But and then... making small stories only works well for a limited horizon. So, now your estimating only works for planning ahead a limited time. You use that to build a general confidence in having a constant stream of feature output. And the same people can then make some assumptions about future projects, based on similar projects in the past. Which works great for feature factories, less so for committing to a tight, hard deadline for a big project that exceeds the limited horizon.
  - 4ndrewl 3y ago
    Need to be sized appropriately to the project and planning exercise. Small stories for short projects, larger ones for large projects. Probably a bit of Goldilocks at play here.
  - cheeseface 3y ago
    This is true, but when it comes to software projects, I don't think you can ever commit to a "hard deadline for a big project" unless the scope (or the cost of the project) is not set in stone.

danielvaughn 3y ago

Just before I left my last gig, I was toying with an idea similar to this. The idea was that our daily “standup” would be entirely asynchronous, prompted via a Slack bot. The bot would grab our in-progress tickets and ask us about each one in turn. For each ticket we give a “gut check”, which is how far towards completion we feel we are (expressed as a simple percentage). A core idea is that it’s not expected for the dev to be accurate in this assessment, just to be an honest guess. Over time the bot would collect and run some analysis on this data, and would then know the average velocity of the team on a per-dev or per-ticket basis. I still like the idea, even though I’ve never implemented it in practice. One glaringly obvious fault is that it can’t really account for outliers. But relying on percentiles rather than averages might alleviate some of that.

janalsncm 3y ago
That’s not a bad idea. Especially given that estimation datasets are extremely small, this could quickly give some better data.
SenHeng 3y ago
That requires that your tickets be atomic enough, meaning project management and planning is still required . Or you’ll end up on a single mega-ticket the entire time.
sverhagen 3y ago
Every story (or task) you're working on should be so small that if you're working on it for more than two or three subsequent daily stand-ups, alarm bells should go off. In your supportive team that means someone notices this during standup and offers to help get you unblocked.
- Falkon1313 3y ago
  That assumes that you're blocked, not making progress every day. If a task typically involves a combination of data structuring, some business logic, and the UI for it, as well as any necessary API, integrations, migrations, and of course automated tests for all that, then it might take more than a couple days. Doesn't mean you're blocked. You say when you're blocked, the clock doesn't.

drewcoo 3y ago

So . . . article claims not just estimation (which is not agile - we all always estimate!) doesn't work, but the rest doesn't work, too. This is obvious BS. Not sure why, though . . . Because the author complains a lot but really doesn't exactly say . . .

jpswade 3y ago

Estimation, especially story points are just a tool to help you communicate and talk about the size of work. Most of the time it’s likely to average just under a 5, so you round up, as most work will fit within a week, which is the underlying “effort” you’re getting from velocity. For a team of seasoned developers you might as well make everything a one and go kanban.

baal80spam 3y ago

NYT is an expert body on software development now?

AugustoCAS 3y ago
I cannot say about NYT, but a lot of newspapers have amazing tech teams. The tech team at FT has an excellent reputation. Unfortunately, some tabloids also have really good tech teams, but I shall not name them because they sell toxicity.
- sam_lowry_ 3y ago
  I once lead the tech team at a smaller news outlet. Software developers join the news and media business because there is a lot of interesting high-load work, the competition in the business is fierce, so engineering tends to be frugal and good. Journalists usually own the copyright to their writings, which by extension applies to software developers working in the same business. Unfortunately, the pay is below the market, people come, enjoy coding, beef up their resume and github profiles with open source code straight from the workplace and go.
petercooper 3y ago
I'd say they're well above the median tech company if there were such a measure. The NYT might be a media company, but it's one that ships constantly, at scale, and over long time periods.

juliangmp 3y ago

Gonna suggest this at my company, see y'all on the stake they'll burn me on

gepardi 3y ago
They might; I suggested we give everything a two, because that’s what the point value was most of the time. I added some thing along the lines of “it will take the time it will take regardless of whatever point value we assign to it.“

devjab 3y ago

I’ve worked as a software developer for a decade and a half now. In that time I’ve had a run at management, I’ve been an “Enterprise Architect” and I’ve had the honour to be selected to work as an external examiner for CS students for the past 6 or 7 years. I’ve spent most of my time in non-tech enterprise organisations, and recently working with non-tech start-ups that are transitioning into enterprise organisations. In my years in the public sector I had the fortune to both make an impact on our national strategies and work along some of the best talent in the Danish Software Industry, both from major software houses and tiny ones. I’ve never seen anyone make good use of estimation. Or indeed any of the agile tools. This is not to say that I haven’t seen organisations make successful Agile, CI/CD, code-as-infrastructure or any of those things operations. It’s to say that it always come with a hefty price of needing a bunch of people to do what is essentially pseudo-work, to enable the processes. In my very anecdotal experience buying and building software with over 200 different companies, and more than 200 different ways of doing project management, I’ve never really seen how any PM techniques have had much of a repeatable impact on quality or deadlines. I sometimes have to work very hard not to snicker when a teacher and a student get into the project management parts or their examinations. Partly because almost nobody does it by the books, but also because it almost never works the way the academics who came up with these process models for “how to work” intended. Sometimes it’s due to incompetence. I can think of very few Scrum Masters or Process Developers or any of those fancy titles, who actually ought to be doing that. Mostly it’s the developers who no longer want to code, for whatever reason, who end up in those situations and as they get further and further away from what produces actual value, they seem to double down ever harder on what ever theory caught their fancy. But for the most part it’s because organisations don’t really want to follow the rules they set up for themselves as soon as the rules get in the way. Yet here we are, grilling students on methodologies that won’t work. I know why we do it. It’s because nobody really cares enough about digitalisation to get involved with managing it. Which means we’re left with managing it ourselves and since every CS student gets “agile good, waterfall bad” into them, and the fact that there is a huge industry that will sell you agile training and models and processes and so on, it’s where almost everyone eventually ends up turning. Because why wouldn’t they? Then we all pretend that anyone will sign your “we don’t know what features we can finish” contract. Or that everyone basically expects your estimates and deadlines to fail. Now now, I know some of you may work in a big American tech company, where these methodologies might actually work out. Because you actually have more than 3 people working on the same thing, and may even have reasonable ways to estimate time because none of those 3+ people will get pulled away at a moments notice to “fix this issue, no. But that’s not the story of software development in general. So on a large generalising scale, things like estimations is basically a lie that we pretend isn’t a lie because business people that don’t care about digitalisation need a deadline for their finance people, so they’ll pretend they believe you’ll keep your estimate, while they secretly have the finance people set off 20-40% extra budgeting for when the estimation eventually fail. Then once those 20-40% are used and they need another 30-50%, things start to get fun. Anyway. I tend to take the “easy” road. I fairly quickly figured out management wasn’t for me. I’ll still do architecture, but I’ll never do it in a way that dictates anything by ever again, enable? Sure, but I won’t boss devs around. Mostly though, I’ll work with development and try to help teams become efficient at building software with the least project management possible. We’ll the PM people be PMs and then let them send their user stories or whatever format they want to the developers once they are deemed so ready that a fresh hire could program them in whatever way they want. Then on the programming side, we streamline as much of the process as possible so they developers won’t have to make a lot of infrastructure or coding-standards decisions, but see completely free to just work on coding. I like that, and as long as our business has enough of a need for developers, I’d encourage people to find what they like and work in that. So when the head hunters contact you, ask them what sort of processes they have, and if they say stuff you don’t like, then hang up. That way you’ll never have to do estimation again unless you chose to. At least for as long as we’re in a buyers market. Once that ends, there is always woodworking.

readonthegoapp 3y ago

tldr; agile etimation is stupid, don't do it. this was an enjoyable read/skim. it had at least one funny. my boss once asked me to track velocity with a small dev team -- we tried half-heartedly, and i had senior folks, who i knew also didn't want to be micromanaged, so i knew we'd get rid of it, and we did after a little while. "OK, i say we skip the estimates/points nonsense this week, and maybe do some work instead, yeah?" "Yeah." and that was that. got rid of most of 'agile', in fact, and got a lot faster. at least, by my estimation. zing.

serial_dev 3y ago

I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows what else (e.g occasional scrum of scrums for a feature nobody understands, across teams and domains, with around a 100 people, with breakout rooms and presentations of all the teams' "commitments"). Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. Once I wrote a script to fetch all the relevant data from Jira to figure out whether or story points give better estimates than simply counting up the stories (because of course Jira makes this as hard as possible for you to find out). I went through the channels, discussed it with different people, at every turn I added more info to the report demonstrating the pointlessness of story points, at each turn the data supported my argument stronger and stronger, across all our teams, for sprints going back years. After weeks of discussing it, we kept the story points, because "upper management wants numbers". Now, I work at a company where we keep things close to the agile manifesto, we adapt as we go, and we aren't forced to play stupid planning poker, and we have twice a week a short sync call (15 minutes). For as long as I have the choice, I'll not work for a company with Scrum and story point estimations.

danwee 3y ago
> Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label? Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.
- 3y ago

regularfry 3y ago

Subtle point, possibly, but: > It’s important to note, though, that the throughput metric applies to teams. An individual does not complete a certain number of points per week. This is an important distinction, because you don’t want your developers to feel judged by the system, or to try to game it by engineering the tickets they take on. This is true, but it's not the main reason to treat the team as the unit of delivery. It's because total team delivery isn't the sum of individual delivery: to treat it like that would be to miss the incidental sideways contributions all the team members have on each others' tickets. If you're doing it right, your most capable people might have very low individual throughputs because they're lifting everyone else up.

deleted 3y ago

[deleted]

scotty79 3y ago

I think agile estimation is a good pretext to have a discussion about work where things come to attention and things get split up if they begin looking too large. Disciplined and insightful developers can have this discussions spontaneously but those are not the people those rituals are for. Points and velocity are orthogonal to this. They might give overseers the added benefit of having some estimate. But they bring along the risk that they'll be used for performance assessment which makes them useless for any estimations and horrible for assessment and bring inefficiencies inyo the discussion during estimation and planning. If points were averaged or forgotten after planning for some teams it might work better.

sethammons 3y ago

The article buried it a bit: cycle time. Reducing cycle time means more value faster. This is a good metric for driving discussions. As for points, the best system I've worked with is 1, 2, or 3 points. 1: we know exactly what to do. 2: we have an idea what to do and we feel the story should not be broken up any further. And 3: we don't know how to solve this; break it up or create a spike to study the problem to break it down or accept the unknown. Everything practically becomes a 2, and is thus in line with the article - the number of stories is pretty reliable between sprints and for projections. The advantage of 1, 2, or 3 over "no points" is that it drives conversions on if something should be broken down. The team quickly starts creating tickets that generally are 2s and pointing a story typically takes a team of 6-8 about 10 seconds. A 3 may be talked about for a minute before it is accepted or broken up as agreed to by the group.

hinkley 3y ago
You’ve basically got small, big, and too big. Which is pretty close to my favored model. FDD is rarely seen but it didn’t do points, it did the Law of Large Numbers. When you have 400 stories you can build trends off of them.

theelous3 3y ago

To ask a question probing at the title... who _is_ it for? Who's doing such well known repetitive tasks that they also need estimation for? Circular black hole imo.

gepardi 3y ago

I resonate with several points. I worked at a place for tickets could have a value of : 1,2,3,5 Most of the time it was a 2, with the occasional 1,3. It’s as if some devs enjoyed the time wasted on the banter if we had a fat one or a skinny two or a fat too, or skinny three. It was such a waste. At one point, I said we should just give everything a 2 because in the end it will take the amount of time that it will take. Regardless of whatever point we assign this ticket. I don’t miss that job. We spent more time grooming and planning and doing retros instead of collaborating.

Braini 3y ago

Obligatory Link to the "Estimates" song by $stdout, its great: https://www.youtube.com/watch?v=sh7A8UChBTI https://www.youtube.com/watch?v=sh7A8UChBTI