9 ms·

Eight points for one team is two points for another team

• tuke 5y ago
  One thing I like to do is try to get all stories to be (approximately / more or less) the same size. I.e., split and gather work so that you don't need to score them. Then you can still get some rough feel for capacity without the bother of sizing. And if you do this, you shouldn't split hairs and be dogmatic.
• 21723 5y ago
  Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, which can be expressed in its gun-language of Jira tickets and so get ignored. Fuck user stories, fuck sprints, fuck Jira, and fuck product management (a job in which one defines success by getting into one's boss's job as fast as possible, leaving no concern for quality) in general with extreme prejudice. If the people who started the computing revolution last century knew that their descendants would be attending daily standups and debating "story points", they'd never have done it--in fact, they'd have blocked it from happening in the first place.
  • jimbob45 5y ago
    Agile is assuredly garbage but having every development company use the exact same process and terminology is too valuable to give up. It reduces training times, increases tool familiarity, and gets the process out of the way of developers.
    • dragonwriter 5y ago
      > Agile is assuredly garbage but having every development company use the exact same process and terminology is too valuable to give up. But...Agile doesn't involve that. Even when the same words are used, they don't have the same meaning, often, and the substantive processes even within vaguely Scrum-ish methodologies vary widely.
      • UnpossibleJim 5y ago
        What has been said so often on HN, AGILE started as a great tool that turned into a cult with no knowledge of why the things being used were being used. Its terminology and practices became mysticism and ritual, with common sense thrown to the wayside. There are exceptions, but in far too many companies AGILE has become a religion that slows the workforce down with high priests who insist that their ritualistic practices be followed and their tithes be paid =[
    • beckingz 5y ago
      This is actually a good point. We should be fighting against the standardization of the industry because it allows more competition for wages. On the other hand, damn near every company seems to only want to hire 'senior' developers who can deliver working software in spite of process, which I assume is somehow related to all the nonobvious process skills being commoditized.
  • randomdata 5y ago
    > Whatever Agile was Has it changed? The Manifesto[1] is still there, unmodified, to provide thoughts on what you need to consider if you are going to run a software project without managers. > Fuck user stories, fuck sprints, fuck Jira, and fuck product management That does not sound like Aglie, especially given that you specifically call out managers, which are incongruent with Agile. The top-down organization where process flows down from management at the top to the developers at the bottom that you speak of is what is colloquially known as 'Waterfall'. This 'Waterfall' organization structure is what many believe the Manifesto was written to counteract, so it is interesting that you’re now calling it Agile. [1] https://agilemanifesto.org/principles.html https://agilemanifesto.org/principles.html
    • moron4hire 5y ago
      That is not at all what waterfall means. And calling "Agile" as the same thing as whatever the Manifesto says is like calling any other religion whatever their holy book "says".
      • randomdata 5y ago
        You’re right in your second point, at least. Whatever you develop out of the thoughts of Agile won’t be called Agile. It is its own thing, with whatever new name you decide to give it.
        • ajmurmann 5y ago
          You can build your own processes around Agile principles. As long as you don't carve the processes in stone and revisit them you still can be Agile.
          • randomdata 5y ago
            Reading the principles of Agile does not make what you're doing Agile any more than reading the words of the bible makes what you're doing Bible, even if you took something useful out of that reading. Whatever it is you end up doing is what you decide to call it. Agile is more like a checklist of things to remember if you're going to operate without managers. Like, stay in touch with the business people, keep your work available for other developers to see, work with people who can be motivated without a manager hovering over them, etc. All obvious when you think about what role managers fill and what you need to do if they're gone, but still a decent reminder if you're serious about going down that road. It's not something you do, rather something you can think about if you've decided managers aren't the right fit for your project.
  • ozarker 5y ago
    I’ve been feeling a similar sentiment. This sprint some higher up agile coach or whatever their title is has been observing our team and making sure we follow the agile law to a T at the cost of real work efficiency.
  • notjustanymike 5y ago
    Your anger sounds directed at the dysfunction within your organization. In particular if you hate product management then you've clearly ended up in a bad place. A good product manager is a joy, someone who is a partner to the engineering team instead of an antagonist.
    • deleted 5y ago
      [deleted]
    • dfxm12 5y ago
      Maybe they're rare, too. I am but one person, but I've yet to work with one that I'd describe as a "joy".
      • happimess 5y ago
        I have, at a truly well-run engineering team. She was fun to bounce ideas off of, and quick to rope in relevant experts, business or techincal. She also understood the value proposition of each feature, and could easily spot if you were wasting cycles on something unimportant. Probably not coincidentally, this was the only place I've worked where KPIs were truly a useful way of framing our place within the organization.
      • notjustanymike 5y ago
        I've spent a lot of my time helping ours grow into a collaborating by walking them through my expectations of a product brief and what we need from our user stories. They're also really good at helping with the release, managing story sign-off and communicating changes with the other teams (customer success, account managers, sales team, etc). A good product manager manages... the product. They also collect all the user feedback, validate feature requests with data, and act as a guard for the rest of their engineering team.
      • soneca 5y ago
        I have worked with a few. It made my job much easier. I’ve worked with a couple that were neutral to my job, but I’ve yet to work with one I hated
  • drewcoo 5y ago
    Big A Agile is what happened after management consultants got hold of little a agile and its manifesto. Now people get certifications in scrum dogma and claim we have to follow the one true way. Now it's entirely about managing people instead of about satisfying customers. That's why a bunch of folks left years ago to work on development as craft.
    • lloydatkinson 5y ago
      Author here, yes, I fully agree about all you said especially certifications and dogma. How can you have a certification, in something that is a list of half a dozen goals? By getting a certification in something else, that isn't Agile! > managing people instead of about satisfying customers. I wrote another article that somewhat alludes to this, it's linked at the start of this one. If I'm not helping people, either customers, or developers by making their jobs easier, then what exactly am I doing as a professional?
    • makeitdouble 5y ago
      I came to think that the whole Big A Agile and small a agile is also just an excuse to put the blame elsewhere. We can't say with a straight face that we expected IBM or Accenture like conpanies to move to an "agile" process. And smal and/or smart conpanies were already doing "agile" without making manifesto and boasting it at every occasion. What's left is the middle ground wh 'll blindly follow any trend and get certifications to proudly have the buzzwords on their company site, and "agile" weren't for them either.
  • drstewart 5y ago
    >technical excellence Technical excellence doesn't pay the bills. Curious - what products do you pay for due to their technical excellence of their backend instead of the value they provide you directly?
    • rurp 5y ago
      There are a great many products I don't use, or use much less often, due to numerous bugs and painfully slow performance. Those qualities are highly correlated with engineering quality, in my experience.
  • moron4hire 5y ago
    Here's one to add onto your list: pair/mob programming is bosses weaponizing employees against each other to "prevent goofing off". I've started to form a belief[0] that large software projects in general are A Bad Idea. Whatever it is, if it requires more than a handful of people to build, it's probably for the greater good of everyone--the workers involved, the users, humanity in general, anyone-not-identifying-as-shareholders--that it not be done. Software is the only thing I can think of where the input effort of creating it is completely divorced from the output work it can churn through. The right program at the right time, written in 10 minutes by just the right person, can save hundreds of years of otherwise manual labor. There's a sort of sense that arithmetic got us out of the stone age, calculus fed the world, computer programming gave us the stars. That sort of power is far too important to imbue into corporations. When you get a large group of people together, they start to think of themselves as Important. And when people think of themselves as Important, they start to think the work they do is Hard. And when they think the work they do is Hard, they start to think the software to help them do their work should be Complex. And none of it comes out of anything other than "we have a large group of people together." Like, microkernel operating systems have a reputation for being slow based on early experiments with them from the 1980s. There are modern microkernel systems that are perfectly fast and efficient and yet people still think "monolith go brrrrrr" and not "all my software lives here" is the reason Linux is any good. Like, I've seen people pitching blockchain-based solutions for municipal information and issue-reporting services, like anything beyond the most basic, not-completely-incompetent, traditional RDBMS is really necessary for such a project. Like, there's a serious cohort of economists that think that the best way to handle social safety benefits is to just give them to everyone who asks, no questions asked, because otherwise the management of welfare benefits gets to be so expensive that it eclipses any potential savings against "fraud". And I'm inclined to believe them. I see people talk about "there's no such thing as a 10x programmer". I think these people have been stuck in ossified institutions so long that they have no idea what it looks like to see a person fly. Cut away 90% of the currently employed software developers. Dissolve the Googles and Facebooks of the world. Don't replace them with anything. Leave us with the 10% of crafstpeople who can actually work through a problem on their own. And make them report directly to the C-suite. No more middle managers. No more grunt work of CRUD forms. If it can be done on paper than it's a waste of time to write software to do it. [0] AKA this is a feeling, not something I've created a double-blind randomized trial to study, dear pedantic HN reader.
  • ltbarcly3 5y ago
    Agile was never good. Agile is a marketing word used to sell useless training to even more useless managers.
  • lloydatkinson 5y ago
    > Whatever Agile was, it's absolute garbage these days. It largely exists to hold developers maximally accountable to the business, at the expense of technical excellence or even maintenance, Author here, this was one of the motivations for writing this and the other article linked at the start. I've seen agile actively harming maintenance and quality more times than I've seen it ever help maintenance or quality. You know things are fucked up when you need to put technical debt, refactors, library updates, etc down as "stories" (erm hello, where is the customer story in "fix that giant performance TODO") instead of just doing them. Sure, we can just carry them out to avoid the wrath of the scrum master and co, but then you have to balance time between doing the stories, and fixing bugs.
• beckingz 5y ago
  1 point per ticket so you can see the jira metrics and try to break down tickets enough that everyone feels they have enough information to get started and understand why the work is valuable. That's enough.
• thenerdhead 5y ago
  This is so true. I've been on teams that did 100x work with like 3 engineers. I've also been on teams that do near 0x work with over 10. What I can confidently state is that you must work the people and then the process to improve anything. We need to stop adopting things just because other teams use them or because they are an "industry norm". If we just truly kept true to the original agile manifesto, there would be amazing results everywhere. Sadly most EMs have the training of a scrum master and never want to work to actually improve their process/discipline. The solution of getting rid of everything is a sound one because at least you can focus on the core agile ideas that make shipping software successful.
  • doctor_eval 5y ago
    Could not agree more. Upper management think Scrum is the only way to do software engineering. It’s a management cult.
  • lloydatkinson 5y ago
    I felt this deeply
  • aaomidi 5y ago
    Our interview process literally selects for people who can spend 20 minutes+ discussing the various ways to approach a binary search. If you're hiring someone who can...somehow make up enough content for 20 minutes about stalling binary search implementation your org is literally gonna turn into places that has tens of engineers and gets nothing done.
• jrockway 5y ago
  I have never seen a ton of value in the exact number of story points, but they are a good way to have the "30 minute debate" that the author decries. If a task is so unclearly written that the team can't get a rough idea of the complexity in a reasonable amount of time, then it's a signal that the story can't be done or that something needs to change; more knowledge sharing, clearer success criteria for the story/task, etc. I get that the meeting is annoying, but not doing the discussion is just going to hide other problems. The longer you hide problems, the more severe they come. Having no idea what the "done" condition is in any of your tickets is tech debt just like long dev cycle times or code that breaks production every time someone touches it; at the project level instead of the code level. If the only problem is deciding between a 1 or a 2 though, I'd just remove "1" from the list of options.
  • arpanet86 5y ago
    Not having good definitions of done is also a great way for a team to feel like it's treading water eternally. Small, achievable goals are a hack for team morale. (The trick is making sure that the small, achievable goals roll up into valuable long-term work.)
    • lloydatkinson 5y ago
      Very true. Experienced this often. Not seeing goals result in anything is a motivation killer.
  • alistairSH 5y ago
    I think the author was saying the 30 minute debate is a problem when deciding between 1 and 2. 30 minute debate over a "100" might be worthwhile, as long as you're doing it as part of refinement and not during planning.
    • jrockway 5y ago
      Yeah, it's a trivial difference. If people are digging in that hard, that conversation seems like a good proxy for other problems with the team. I've had votes split between 1 and 2 a number of times. That's a 2. (My planning poker algorithm is: 1. Vote without discussion. 2. If the votes all agree, that's the number of story points. If the votes are within 1 of each other (1, 1, 2; 2, 3, 3; 8, 8, 13) then it's the highest (2, 3, 13). 3. If there isn't that much consensus, then someone with the lowest vote and highest vote complete the sentence "To do this task..." 4. GOTO 1) This is unbounded, of course, and sometimes no consensus can be reached. That usually means more definition is needed, and you can take on a task to do that definition for the next planning meeting. When there is disagreement, it isn't always bad. Sometimes an old hat will say something is a 1, and the new person that just joined the team will say that it's a 13, and the senior person will say "To do this task, edit foo.yaml and commit it." and the junior person will say "To do this task, I need to set up my workstation, then build a test environment, then read all those getting started instructions, then get access to production, ..." and you'll realize "Oh shit we never had the setup onboarding meeting" and you can just do that. Whereas if you just said it was a 13 and assigned it to the junior engineer, they still wouldn't be onboarded after struggling through all of that on their own. I don't want to sound like an agile advocate or anything, in fact I'm pretty disillusioned by agile, but I've used this before and don't have a big problem with it. Looking at story points over a period of time is good for taking on the right amount of work in any given cycle; if someone says "we need to launch this next week" and your team does 15 story points of work per week, and the project is 1000 story points, then you know that that can't happen. Numbers to prove it! Someone can work on reducing the scope in the meantime. I think people try to get way too much out of agile, like on day 1 setting launch dates for features a year out, and that will never happen. That is why people are disillusioned, "I set up a 6 hour sprint planning meeting and bought a JIRA license, and we still aren't launching 3 new features a month!" Yeah, the actual work is still time-consuming; moreso on a larger team with changing opinions and changing markets. So it goes!
• deleted 5y ago
  [deleted]
• js8 5y ago
  This reminds me of the now classic article: http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile_27.html http://steve-yegge.blogspot.com/2006/09/good-agile-bad-agile... It essentially claims that "good agile" is Kanban, and Kanban is essentially abolishing of any forecasting in favor of actually doing the tasks, like the CPUs do when executing programs.
  • mickimnet 5y ago
    Not debating about estimating or not. I'm only replying to the example: CPUs can only execute, what the instructions tell them to do—like a production line—and not solve / create something (new).
    • henryfjordan 5y ago
      Kanban was originally designed for production lines in car factories, so it works. If you go to any McDonalds and look at the screens in the back you'll see orders represented a lot like tickets. In Agile, "points" are just an abstraction around work to try to normalize it in the same way that every burger+fries combo should be roughly equivalent.
    • nescioquid 5y ago
      Not sure why you were down-voted, but this is a good point. In fact, it is the base problem of all software methodologies. Planning depends on knowing how long an activity will take. Estimating is most reliable when you are estimating something you've already done before. Unless you're working in just such a low-novelty environment, your results will not be predictable and you should understand that the backlog is a priority-ordered list and velocity will let you give a "forecast". Kanban doesn't "fix" this -- it just changes the frame through which deadline-buzzards get to look at it.
      • js8 5y ago
        I would say, if you absolutely need an estimate on how long a project will take (and often you don't), do a proper study on it, don't just pull a number out of your a*. Software project estimation is doable, but it takes some effort. It (IMHO) cannot be replaced by a clairvoyance seance, AKA planning poker.
• citilife 5y ago
  "points" are just a way to avoid being held accountable. If we were to use hours (even buckets of hours, aka: 1, 2, 4, 8 hrs) we'd be better off. It'd be more transparent and while it may differ between team members, we can hold people to account who over / under deliver based on their estimations. The entire point is to estimate velocity (supposedly), so why not have a feedback mechanism that's let engineers learn to estimate better; instead of using an abstraction. I for reference, have multiple agile certifications and just don't understand.
  • arpanet86 5y ago
    That sounds wildly micro-managey. I often don't know how long something is going to take until I dig into it; sometimes I don't know how long something is going to take until I'm almost done. The ambiguity/fuzziness of points is a feature, not a bug. If I'm going to be "held to account" based on my estimates, I will optimize for producing work that matches my (naive, uninformed, up-front) estimate, rather than producing the _right_ work. This will last for a few months, at which point I will realize I'm burned out, working inefficiently, and writing bad code, and I'll find a new job on a different team that doesn't treat its employees like train conductors.
    • nelgaard 5y ago
      True. But on the other hand an experienced developer usually can give a reasonable estimate. An if he says: "about two days maybe a week" then that is you best estimate. Using story points is just another complication. And points do not stop anyone from holding you to account, if that is what they want to do.
  • codenesium 5y ago
    The point of "points" is nobody can estimate how long a task will take and it gets worse the larger it is. So it's better to have reference tasks of a certain size and complexity that you do know how long they took and compare to those to get a general idea. You could use hours in that context but it's trying to make you think is terms of size and complexity not hours.
  • 5y ago
• notjustanymike 5y ago
  This post is starting to fill up with what sounds like a kind of hopelessness mixed with anger against Agile. It's possible to do sprints, pointing, demos, and retros well, but you have to own it as the engineering team. This means understanding and adapting the process to your needs. Agree on your definition of done. Set boundaries for pointing. Prevent confusing or unfinished stories from being point. Communicate how you work to the greater org, and get buy in. Use retros to constantly iterate and improve your process.
  • itronitron 5y ago
    My experience with Agile has been that it is a powerful equalizer of everyone on the team. The degree to which a person's productivity is equal to others on their team may impact whether they consider that a net positive.
  • nine_zeros 5y ago
    When there is so much overhead in process, the process is a waste of time. Management needs to skill up.
    • notjustanymike 5y ago
      Oh management absolutely needs to skill up. One of the major reasons Agile annoys engineers is because the process is owned by an individual who doesn't understand why they're doing it, or how it can be changed. Personally, I've found retros to be most important area for a manager to focus. They can be a wonderful source of discussion and improvement for the team, or one of the most boring hours of your week.
      • nine_zeros 5y ago
        Having been in 300 retros, I assure you that the process overhead is large enough that any other process is more efficient at this point.
  • msandford 5y ago
    "Just demand the respect that the business isn't giving you. What's the worst that could happen?" You didn't say exactly that, but that's kind of the undertone of what you wrote. If you live in the US and you demand your right to a fair trial, well good on you. But if you live somewhere perhaps less committed to such a thing, making the demand doesn't mean anything other than you're naive and foolish. So it goes in some companies as well. If they don't have the values the demand isn't you being courageous. It's you painting a target on your back.
• woojoo666 5y ago
  I use story points and estimation for my own personal projects. They are private numbers that only I can hold myself accountable for, so there's no reason to be dishonest. And they help me plan and gauge my trajectory and what I need to prioritize.
  • wellpast 5y ago
    This is exactly what I do. I do this in my job as well, but privately. Making myself my own product manager. Do you use a tool to do this? Spreadsheet?
    • woojoo666 5y ago
      Plain text docs for now, looking for free open-source kanban in the meantime
• arpanet86 5y ago
  The (very real) problems the author cites are problems with management, not story points. "Pressuring or coercing... Immediately discounting... Comparing and judging..." It doesn't matter what project management tool/technique is the object of these actions; the actions themselves are the problem. I hesitate to play the "you're just using them wrong/misunderstanding them" card, but it's worth at least alluding to its existence. Like any other tool, story points are powerful and helpful in the hands of people who want to and know how to use them to improve things, and difficult or even destructive otherwise.
• wellpast 5y ago
  > “Building the wrong thing on time and within budget doesn’t buy you much.” Let's get one elephant out of the room out right away. Many in the #NoEstimates camp are speaking from the position of some enterprise context where the business technically has already built the right thing, they have revenue, aren't innovating much (by design), and as long as they keep the ship afloat and don't make too much of a mess of things, they're fine - or at least engineering isn't going to be the deal breaker. Estimates or no-estimates in these context-- who cares. Literally anything you do on the engineering side means nothing to the upside of the specific product line you're working on, and if you look around you in these contexts, you'll find gross and massive inefficiencies abound and none will have anything to do with your dev process, agile, estimates, no estimates, what-have-you. For the rest of us, you live and die by execution, which includes your ability to prioritize what you're delivering, all of which means nothing if you're not estimating - however indirectly or directly you are estimating.
  • lloydatkinson 5y ago
    > all of which means nothing if you're not estimating It also means nothing if all your estimates are so totally wrong and not based in reality, as I mentioned a few times in the bullet points.
    • wellpast 5y ago
      Same is true for every other aspect of your work. If your code is wrong, then you’re losing too. You’re saying a tautology. Being able to estimate, being able to market, being able to code — these are all competencies.
• tuke 5y ago
  It is worth noting that Scrum, for one, does not require (or even recommend, at least according to the latest Scrum Guide) story estimating or pointing. I would agree that in practice all of those anti-patterns related to story estimating/pointing can work against the values of the Agile Manifesto.
• d23 5y ago
  Yeah, it's all a garbage dump. The only thing that matters in most cases: roughly how much time is this going to take and does that amount of time change the task's priority. If there are external teams who need to have the timelines communicated to them, communicate it to the degree you are certain, and then calm down and do the work.
• d23 5y ago
  The whole thing is built on the pretense of a level of coordination I've never seen exist at a company.
  • lloydatkinson 5y ago
    I never have, either.
• rurp 5y ago
  The funniest agile system I've worked under was with a totally incompetent manager who graded us on number of tickets. Despite supposedly having a technical background he knew almost nothing about software engineering, and didn't care to learn, but needed to feel some sort of control so he would count up tickets each week and berate anyone who hadn't done enough. Once I got over the initial horror it actually worked out pretty well. I would keep a stack of trivial work on standby for any time I needed to show some board progress and then used the majority of my time to dig into whatever work looked most interesting.
• 60secz 5y ago
  Don't drink the koolaid. 1 point is the amount of work an average developer on the team can complete in 1 day of work (4-5 hours) Anything else is "Fugayzi, fugazi. It's a whazy. It's a woozie. It's fairy dust."
• lloydatkinson 5y ago
  Author here. Glad to see my article resonate with so many developers, both on here and reddit. I was expecting a lot of anger and spitting of feathers but as it turns out many people are really not happy with agile (or as I like to call it sometimes, badgile). I think, as an industry, we're all a little frustrated and fed up of this whole debacle.
• chester_the_dog 5y ago
  I worked at a company where the scrum master told us that a story point had to be a fibonacci number. Has anyone heard of this? The original Agile Manifesto demonstrates the collective wisdom of people who have written a lot of software. Note that the Agile Manifesto doesn't mention a certified scrum master, or any role similar to it. It says that business people and developers should work together. It does not say that a certified scrum master should leave the stand-up meeting every morning to spend an hour giving a status report to the CTO.
  • etblg 5y ago
    Fibonacci story pointing is good, at least in my opinion. It removes a lot of the granularity of pointing, and forces the larger points to grow very fast. You still have some nuance between 2, 3, and 5 pointers, but once you start getting past that the numbers jump to 8, 13, 21, very fast. You don't need to spend time with your team debating whether something is a 5, 6, 7, or 8 pointer, it's closer to a 5, or its closer to an 8, if it's higher than an 8 it jumps up to 13. Less time spent circling around an exact number and quicker to get to a "is big" "is medium" "is small" "is trivial" decision.
• forgotmypw17 5y ago
  I've worked on about 10 different teams using some variant of Agile, and I only recall one which was able to achieve accurate estimates for a complex software product... What's the secret? Story points are only the beginning. They are an estimate which must be updated during the planning meeting. Our planning meetings for a team of fewer than 10 people took the better part of an entire workday -- 8 hours. What we did during those meetings was pick apart the user stories into small developer tasks until there was no task larger than 3 story points on the board, ideally all of them one-pointers, with one point being an estimated 1 hour of work. We also spent most of an entire day for each retro meeting. Edit: Our definition of done was signed off by the QA Engineer.
• Kaotique 5y ago
  Scrum, Kanban or more general Agile are like recipes. They describe the process and ingredients exactly but everybody does it their own way anyway. It is just a theory, you have to execute it and adapt it to whatever you have available.
• colburnmh 5y ago
  The fact that this is an issue all of the time amazes me. Yes, teams have a different measure of how much work they can get done every sprint, but as long as that measure is accurate, it doesn't matter. Here the thing: two teams may operate at completely different rates: One team (more experience devs with more mature technology) are going to be faster than a new team with new tech, even if they have the same number of devs. You can't just assume that both of them can do 25 story points of work every sprint. The teams can only go as fast as they can go. It's analogous to the fact that two different people have different rates of walking or running. You can't make them the same unless you are willing to lose efficiency of your fastest walkers/runners. The fact that one team expresses the quantity of work they do (i.e., English vs. Metric) isn't important as long as they actually hit their estimates most of the time, and improve their estimation accuracy.
  • lloydatkinson 5y ago
    Yes exactly, one of the reasons I wrote this was because of abuse of story points.