Timmy is the guy that was so annoyed by a company not fixing a bug that he specifically got hired to fix the bug and then quit again, because it is faster.
They kinda do, story points are basically proxy based estimation - installing this type of window the last time took this amount of effort, and this task will take roughly the same effort .Let's label it 3.
Can be used to obfuscate the measurement of time or complexity so you’re not using a unit like hours which is too specific. It’s so devs don’t feel like management is breathing down your neck and measuring every hour you work. It’s a “looser” unit of measurement that allows for wiggle room because it’s impossible to figure out exactly how many hours a task will take. And it’s still good for management so they can get a rough idea of how much work a team can complete to do longer term projections.
@@CookieCurls It's actually less complex than that. Humans are bad as time estimation (things which should take an hour take days instead, and things you think will take a week might end up in an afternoon) but humans are pretty good as estimating complexity in comparison to something else. Thus a story point is supposed to be a relative complexity to something else. If you think something is twice as complex, it's 2x the story points, if it's half as complex it's half the story points. Story points have no other meaning. However, if you look at dozens or hundreds of story points across weeks of development, patterns start to emerge on the average value of a story point. This is entirely dependant on team. The average value of one story point for team A might be 2 days, where as for another might be 5, it's also different from developer to developer too but it's designed to average out.
@@HansUhligEither you’re quoting some “rationalization” from a middle manager, or you’re onto something with this different trends for different groups thing…
@@Minnieal28 I'm just speaking from years of experience. The entire point of story points, planning poker, or t-shirt sizes, is to roughly gague with some arbitrary value the complexity and therefor effort required to complete some chunk of work for a given team. Since most people suck at proper time boxing, you make the scale entirely arbitrary and relative. It's relationship to an absolute measure like person months is estimated based on the average complexity completed per cycle for a given team. So if on average your team completes 15 units of complexity a week, that's roughly the velocity of that one developer or team. A different group may have both a different absolute and relative velocity and a different relative complexity measurement. A good team leader should be able to properly gague and plan for their team based on metrics established over months and years. Clueless PMs who try to coerce those numbers into division wide metrics are not only idiots but doing their entire organization a disservice. The entire reason you use arbitrary relative measures is because trying to pin down any one task to an absolute pre-defined number is silly and almost always wrong. Story points are complexity estimations, not time boxes.
Speaking as a lead developer here, all of this guy's content is spot on. The amount of inefficiency and corporate waste that you are subjected to when you are one the people that actually builds and maintains the products that make companies money is absolutely insane. It really opens your eyes to how many jobs in corporate America are completely useless wastes of money when you have to deal with crap like this.
As someone who has worked on both sides, Story Points are a good way to organize a quick understanding of how difficult a task is and how long it should take, and properly distribute the work that way. The issue is that people who don't know how to do proper management, or how to fit these structures in, try to implement it because they've been told it's a good idea, but don't actually know what they're doing, so they don't run it correctly and, most importantly, they don't work with the team to explain to them how this is supposed to work. I've seen it used very effectively, but if management doesn't know what they're doing, it would be better to just not try things like that. The problem is most managers are incompetent.
Story points exist so that managers need to do a little math before they can harass you about the timeline on that super vague ticket they asked for a "rough" estimate on 3 months ago 😅
It's an estimate for complexity, not time. There you are. It should be repeated every time a team is formed. A story point is translated into time _only_ when the task is assigned to someone with a given velocity. Moreover, members may tackle only tasks of up to a certain amount of SP, because they don't have the expertise to work on more complex tasks. So, if Antony can do 20 SP per sprint, Timmy can do, like, 5 - but maybe he also can't do tasks of more than 2 SP because they're outside his capabilities and a 3 SP task may actually take all of the sprint or even more.
You were right until you started measuring velocity at the individual level. Velocity *only* makes sense at the team level, because different people are good at different things and the team can always help each other out. (and the other reason is that if you start measuring it at the individual level, it starts getting used as justification for bad performance reviews... and then the smart devs start gaming the system instead of actually getting work done)
Ok but actually story points exist because the average person can't actually tell you how long something will take but they can roughly approximate how hard the task is. Removing time as the metric makes it way less precise but way easier to be accurate. But yeah magic is correct
I once worked in a place where Scrum was exclusively run by devs. It was the most efficient place I ever worked. Everywhere else, scrum is run by non devs and is a literal hellhole
Time estimations are useless most of the time because they are never accurate. Story points are supposed to estimate complexity of a task compared to other tasks.
Estimating complexity is obviously more accurate and more useful than estimating time. If a request comes down to switch to time estimates, shut it down fast. The main issue with complexity that I find is that if you use a non linear scale as most do like fibonacci, it makes the value of the velocity number (which is the sum of multiple complexity estimates) very limited, because that single number doesn't represent what numbers were involved in arriving there. Eg 20 could mean 4* 5 pointers, but it could also mean 10* 2 pointers.
Time estimations are useful most of the time because devs usually have an idea of how long time something usually takes. Story points use a more abstract sense of how 'complex' something is, so you don't get even a rough overview of how many workhours is needed. You can apply both systems to anything, from reading 5 chapters a 5 pages in your book, or making dinner, and if you choose story points you are bad and should feel bad.
This the kind of shit that makes me glad im a sysadmin who lives in an ice cold server closet playing videogames with the hum of servers, switches, routers, and UPS's in the background.
Real answer should be: "story points are how we measure complexity. In our team, we count story points in terms of..." For example, the team might just rank features by complexity. So a working button might be worth 1 story point, an API call 2 story points, and something more complex than either 3 story points.
Am I the only one that actually thinks story points are a good idea? Quote on the compexity of the job, the time it takes is based on who gets assigned it. A junior or new starter gets more leniency compared to a company veteran or senior.
Jira is software for tracking projects with tickets. Boards are a feature in Jira to show your team's tickets grouped by status. It's called a board because back in the day teams would use sticky notes on a whiteboard to keep track of the tickets. Usually there would be a couple of vertical lines drawn on the board to make spaces for each status (defined, in progress, blocked, done, etc..)
She's not wrong though. Time estimate are always bad and are "unjust", as a senior dev should always require less time to do a task than a junior dev. Story points bring this to a neutral zone, as you'd simply expect a senior dev to be able to tackle more points per week.
@@bigpod But it explains to the boss, when is it going to be done... Well its a 5, so for Jack that's probably this week and Jill its probably tomorrow.
I truly have no clue what story points represent. I worked in a company that used them but no one outside management even got to see the estimates. The rest of us got time estimates which were wildly unreasonable.
It's really "magical" that SP are not time based, but if you dont finish it till sprint end you're screwed. So don't listen to them if they deny it, do it a couple of times and you get fired for sure or at least have a performance meeting! :D
story points are a subjective unit of measurement used to estimate the amount of effort needed to complete a task or issue. They are a core concept in agile planning and are often used instead of traditional time estimates. Story points are based on estimated effort and complexity rather than actual hours worked
Well, I just spent the last hour or so learning about scrums and sprints and user stories and epics. I'm not sure whether to thank you or send you a bill :)
Story points are easy: they mean jack shit. Lower numbers mean little work, bigger numbers mean much work, anything in the middle means fuck me I don't know how long this will take. Source: Am PSM certified. Now do burn down charts lol
Story points are based on the length of a sprint, but what really pisses off Agile teams is when the developer gets handed a requirement document with 150 output field definitions, all different for the four output records you're supposed to produce for each data point, and tells the team that they don't have a number to represent effort unless it's in months. "But can't you do it in a sprint? Two weeks should be long enough."
