|
Bugs should not have points because bugs are added to the codebase as part of other work. You already got the points for the bug when you made the change that introduced the bug - you just got them in advance. Now you need to finish the work.
|
#
?
Aug 30, 2018 16:43
|
|
|
|
| # ? May 9, 2024 21:26 |
|
|
Scrum is a form of agile with poo poo piled on top that just produces graphs to keep management happy.
|
|
#
?
Aug 30, 2018 16:56
|
|
|
BaronVonVaderham posted:
honestly the key to handling this scenario is to just pretend that scrum and story points don't exist. don't go to the meetings, don't go to the grooming, figure out your assignments through side channels. the only thing showing up for meetings will do is make you seem available and motivated - this is bad for your career because if you're too available, you'll end up working on stupid bullshit, and if you seem too motivated, you might end up a manager in this horrible environment. it's a religion, it dies if people stop showing up. Bruegels Fuckbooks fucked around with this message at 17:00 on Aug 30, 2018 |
|
#
?
Aug 30, 2018 16:57
|
|
|
Become a manager, then use that promotion to help you find a better job
|
|
#
?
Aug 30, 2018 17:08
|
|
|
Sadly not really an option for me. I'm already the only remote dev (I don't count our overseas devs, who seem more like contractors to handle busy-work like copy changes and fixing minor CSS display bugs and poo poo), I can't just go rogue and stop showing up for meetings.....sorry, CEREMONIES, because Scrum isn't enough of a cult already.
|
|
#
?
Aug 30, 2018 17:10
|
|
|
Time to  ?
|
|
#
?
Aug 30, 2018 17:32
|
|
|
Mega Comrade posted:Scrum is a form of agile with poo poo piled on top that just produces graphs to keep management happy. You're not wrong, though if everything is flowing it can definitely help the business people actually have accurate estimates of when things will be ready, and makes them feel like they're actually a part of the process even if their input is neither present nor required. Done correctly, it effectively buffers the developers from the management and business layers that slow everything down. BaronVonVaderham posted:meetings.....sorry, CEREMONIES Eject Volmarias fucked around with this message at 17:54 on Aug 30, 2018 |
|
#
?
Aug 30, 2018 17:52
|
|
|
If it's any consolidation: As an agile manager type of person, I would have happily chucked the numbers or made up whatever was necessary to satisfy the machine while people got poo poo done. Even though it's prob put a lot of dollars in my pocket, a part of me wishes this whole "agile" thing hadn't blown up. There so much cargo cult superficial bullshit, it's just makes everyone cynical 
|
|
#
?
Aug 30, 2018 17:58
|
|
|
Bongo Bill posted:Bugs should not have points because bugs are added to the codebase as part of other work. You already got the points for the bug when you made the change that introduced the bug - you just got them in advance. Now you need to finish the work. Points are a measurement of work/effort. Do you work when you fix bugs? Then you should track the amount of work you did. BaronVonVaderham posted:There was major pushback because THE POINTS! THE POINTS WON'T BE ACCURATE! We won't "capture" that work that way! Why would the points not be accurate? Are estimates only made in big, slow meetings (bad) or only by the "scrum masters" (worse)? Anyway being a remote employee with no work to do and someone else to shift blame on sounds like an ideal working scenario, enjoy your vacation. e: There's basically 2 use cases for points. The first is prioritization before work: "I have a capacity of 5 points per sprint, so I can't do both 3 point stories." The second is retrospection after work: "I typically do 5 points per sprint, but I spent 2 points worth of time being on-call/fixing critical bugs (so let's adjust our expectations for next sprint)". Assigning points should not be a difficult process. If it's taking too long in meetings due to discussion, your tickets are not defined well. And it doesn't have to happen in meetings -- if I file and work on a critical bug, I can assign it an estimate without involvement from anyone else. If I'm way off, I can just change it to the work I ended up doing, or timebox it and file followups. Also you shouldn't expose points to team outsiders, or even worse, be responsible for delivering exactly X points of new work. No true agile, etc etc, but I've actually seen this system work. Pie Colony fucked around with this message at 18:35 on Aug 30, 2018 |
|
#
?
Aug 30, 2018 18:13
|
|
|
Volmarias posted:Done correctly, it effectively buffers the developers from the management and business layers that slow everything down. Yeah this is the one thing that they do do well, or at least the BA on my team does (my other team I was shunted over to for 2 months was godawful and the BA didn't even know what was going on). My last job they did the exact opposite: There was no management layer, just a team lead to coordinate standups and poo poo, and it worked REALLY well.....except for the lack of insulation from business, leading to me having to communicate directly with product owners and even customers. Cue the usual bullshit that comes from a way-too-democratic design and planning process, and nonstop OMG EMERGENCY  requests for poo poo like minor copy changes or altering the color of a button.The biggest problem I have with the whole paradigm is that it's based on absolutely nothing. There is no research that says this is effective in any way, it's based on one dude's gut feelings from 20 years ago or something. It's entirely made of buzzwords and specialized lingo that is catnip for management types, but doesn't actually add any observable benefit. It can accidentally work, but most of the time it just gets in the way and spawns entire careers centered around managing imaginary nonsense. It seems most effective in a small start-up environment where your goal is just to produce something, ANYTHING, to get a proof of concept to attract investors. This artificial, constant, panic-mode mentality is inappropriate for an established company with a steady revenue stream.....if you can hire a dozen managers for ten devs, you don't need scrum. I've been slowly working on ideas for any kind of alternative that's based on something actually measurable that can be used as a real metric for team performance. My best concepts so far are things like number of hotfixes or rollbacks required, number of requests for changes required on PRs, and accuracy of time estimates.....all of which work far better in a continuous integration scenario rather than arbitrary 2 week sprints for no actual reason. Hell, this makes it easier to pick apart what breaks something upon release, rather than having to tease apart and try to revert a tiny piece of a monolithic release where none of the pieces actually need to all be tied together like that. Programming is a very fuzzy process, something I've had to explain at length to my gf who has been fascinated to watch this train wreck (she is doing a doctorate in Applied Behavior Analysis, so that's where all of this is coming from): It's not an easy process to break down into easily defined tasks, or to know exactly what's going to have to be done to fix a given bug or add a given feature. You could at least look at overall trends to gauge performance; if you're off on 2 or 3 stories in one release, that's normal. If your team is consistently under-(or over-)estimating on these deadlines every release, then that's a clear indication that something's amiss. Pay for performance (which would be the end goal) is such a hard concept to tie into such a field that is very hard to pin down, but I feel like at least picking out things that are actually observable and tied to measurable products would be a vast improvement over everyone trying to collectively agree on imaginary numbers. It's just a matter of figuring out what those actually are....and then convincing an entire industry to stop drinking the agile kool-aid, which will never happen. I'm trying to fight back in a low-key way, but it's going to take a while to change minds when you have an entire class of employee whose entire job is to keep this process in place who will literally be fighting you to save their own job. Side note: I actually love this job! It's by far the best position I've had (though admittedly that's a low bar to clear after the startup owner who expected me to be on call 24/7 for over a year straight, the nonprofit that underpaid me by almost 50% but I tolerated since the schedule let me go back to school, and the last place that sold us out to a megacorporation that cut my insurance and didn't tell me until 4 days later). I love my fellow devs, we work incredibly well together and have a ton of fun. My BA is actually amazing, she is SO loving fierce in protecting us from business demands and I love her for it ("If ANYONE tries to pull you off of this story to work on something else, message me, I will hunt them down and put and end to it."). It's just so frustrating to see so much inefficiency holding us back from kicking even more rear end, and I'm so sick of sitting through endless, pointless, tedious "ceremonies" that distract me from doing what I actually enjoy doing: writing code. Point of perspective: I have written zero lines of code since last Thursday. In four days I've spent upwards of 20 hours in meetings about this sudden shift to the new project (we're expanding into Canada, so the few actual dev meetings to brainstorm implementation of poo poo like currency conversions are actually necessary and interesting). Pie Colony posted:Why would the points not be accurate? Are estimates only made in big, slow meetings (bad) or only by the "scrum masters" (worse)? We have a once-a-week "grooming" meeting and it's clear no one but the scrum master has any investment, we all just want to get it over with so we can get back to what we're simultaneously being told has to be in before the ever-earlier code freeze (currently we release on Wednesday night, code freeze begins Friday). Something something work done outside of the sprint not being accurately captured bullshit bullshit nonsense? I have no idea. I am truly baffled by a dev going, "Hey, we can totally knock out these bugs," and being met with GUYS STOP DOING WORK! But yeah, like I said in my first post about this, I honestly stopped caring and fighting with them over it, it's just really frustrating to watch happen. If they want to pay me to go take a nap, I'm not really fighting all that hard to change it. I'm delivering my work and meeting my deadlines, they're happy with what I produce, so I call it good and just rage about this outside of work because I have an unhealthy obsession with efficiency and elegance (hasn't been said yet: my degrees are in physics, so this is a deep-rooted obsession for me). It truly, deeply bothers me to imagine just how many resources and man-hours are wasted nation-wide if you think about how many companies are incorrectly implementing already-flawed processes, and my brain doesn't stop itching until I find some way to fix a problem I find. e: Pie Colony posted:e: There's basically 2 use cases for points. The first is prioritization before work: "I have a capacity of 5 points per sprint, so I can't do both 3 point stories." The second is retrospection after work: "I typically do 5 points per sprint, but I spent 2 points worth of time being on-call/fixing critical bugs (so let's adjust our expectations for next sprint)". One company I was at briefly actually said a point is an actual hour of work. We'd make estimates, but we weren't held to them. You finish the story, you update the points to reflect the actual time worked, or we had two fields for estimate vs actual or something (it was a long time ago). There were no sprints, just CI, release poo poo as it gets approved and tested, then grab the next card in line, and the managers just managed the priority of things. By far the most efficient and easy-to-manage system I've ever been a part of. Everyone knew what they had to do and just did it. BaronVonVaderham fucked around with this message at 18:37 on Aug 30, 2018 |
|
#
?
Aug 30, 2018 18:34
|
|
|
We estimate stories so our product team knows what needs the most refinement work and definition (in other words, what they should be working on). We don't really care if people go slower than the estimates, but going faster means the product team may need to readjust their priorities so stories are fully scoped by the time people are ready to work on them. Optimize for team flow state. Ignore everything else.
|
|
#
?
Aug 30, 2018 19:06
|
|
|
Vulture Culture posted:Ignore everything. This is how I prefer to work.
|
|
#
?
Aug 30, 2018 19:14
|
|
|
BaronVonVaderham posted:There were no sprints, just CI, release poo poo as it gets approved and tested, then grab the next card in line, and the managers just managed the priority of things. That sounds like Kanban.
|
|
#
?
Aug 30, 2018 19:46
|
|
|
New Yorp New Yorp posted:That sounds like Kanban. THAT was the word they used for it. I couldn't remember it for the life of me, thank you!
|
|
#
?
Aug 30, 2018 19:59
|
|
|
New Yorp New Yorp posted:That sounds like Kanban. Kanban worked better than Scrum on a team I was on. We had lots of tasks we couldn't estimate very well, because everything was a situation like, "We want to do this and it might be so complicated that we decide not to do it at all." After multiple sprints where we overinflated the story points on everything, then got everything done in the first couple of days because things turned out to be not so complicated or we decided not to do them, we started making separate "Investigate this" and "Do this" tasks that added their own annoying ceremony to the process. (The investigations also didn't add "value" on their own and were, thus, not technically capital-S Scrum.) So we switched to Kanban and prioritized our goals, instead of our tasks, then started popping them off in order. It went much more smoothly, until management started poking their nose in and trying to quantify our process. We were informed by the Scrum Master, at the behest of the bosses, that our velocity had dropped below our rolling average and we needed to improve that. One of my coworkers just pointed out that half our sprints would be below average and half would be above, so that feedback was entirely meaningless. So basically, every Agile strategy is fine until management gets involved. Or maybe just everything is fine until management gets involved?
|
|
#
?
Aug 30, 2018 20:00
|
|
|
Pie Colony posted:Points are a measurement of work/effort. Do you work when you fix bugs? Then you should track the amount of work you did. Points are the unit used to describe an attribute of a story. If you want to describe the amount of work actually done, you can just use a clock and measure it in hours. (Don't estimate the amount of time it will take, though. You should never give an estimate in hours for the same reason that you should never give an estimate in lines of code. I don't think it makes sense to give time estimates in anything more granular than weeks. If somebody asks you for an estimate in hours, they are probably asking you to lie to them, and they may not realize that's what they are asking.) If there's a bug, it means some previous story is not actually done, and was accepted erroneously (because it failed to meet the implicit requirement that it doesn't break anything else). A story being incomplete (usually) doesn't change the requirements, so it shouldn't change the points either. A consequence of this form of measurement is that it means a way to increase velocity is to write better code so that there are fewer bugs and that time can be spent on features instead. If you point bugs, it becomes possible to increase velocity by writing worse code so that more bugs are opened and less time is available to spend on features.
|
|
#
?
Aug 30, 2018 20:09
|
|
|
CPColin posted:So basically, every Agile strategy is fine until management gets involved. I often feel like every reporting metric management uses is wrong. Vague and noncommittal responses are my dearest friends.
|
|
#
?
Aug 30, 2018 20:19
|
|
|
CPColin posted:So basically, every Agile strategy is fine until management gets involved. Everything is fine until anything gets involved.
|
|
#
?
Aug 30, 2018 20:30
|
|
|
Rubellavator posted:I often feel like every reporting metric management uses is wrong. Vague and noncommittal responses are my dearest friends. My favorite misuse of story points was when middle management was trying to prioritize projects/epics and continued the Fibonacci numbers into the three-digit range. So they were trying to reason about a 610-point project vs. a 987-point project vs. a 144-point project and poo poo. Later, I learned that they should have just started the gently caress over from 1 and not tried to make epic story points equivalent to task/bug story points.
|
|
#
?
Aug 30, 2018 20:32
|
|
|
Ah, I see it's time of one of THESE posts again. A true classic in this thread. - Poster claims scrum is bad. - Poster lists a bunch of things that are done in the name of scrum at their company and that are bad. - At closer inspection, each and every of the things listed are definitely not scrum, with most of them being actively anti-scrum. - Conclusion is that poster's company does not use scrum at all, instead they use some crappy "process" that's only called scrum because that word fell off the hype train while management was watching. - Poster still blames scrum, giving fresh developers who want to give agile (the real kind, not the led-by-management kind) a try a sour taste about it from the start.
|
|
#
?
Aug 30, 2018 20:59
|
|
|
Pie Colony posted:Points are a measurement of work/effort. Do you work when you fix bugs? Then you should track the amount of work you did. Estimating points on bugs can also be very difficult when you don't even know what the cause of the bug is. Estimating points on bugs can be helpful to help figure out timelines for stuff in the short-term, but you shouldn't use bug fixes as credit toward velocity. Fixing bugs contributing toward increasing your velocity could maybe be justified if you estimated work by also estimating the number of bugs and effort you were going to generate out of every story you do, but I think that's just starting to over-complicate it. You can already build this into velocity by not getting extra points for fixing bugs.
|
|
#
?
Aug 30, 2018 21:06
|
|
|
BaronVonVaderham posted:
Sprints are a really stupid loving way to organize work, especially when you start getting insane management decisions hyper-focused on these X-week windows. I think it's a misguided management perception that you can get extra work out of workers with constant short-term deadlines. Work really should just be organized around taking poo poo off a priority queue.
|
|
#
?
Aug 30, 2018 21:13
|
|
|
Carbon dioxide posted:- Poster still blames scrum, giving fresh developers who want to give agile (the real kind, not the led-by-management kind) a try a sour taste about it from the start. Rightly so, because that's the kind of hellscape found over and over again in countless orgs.
|
|
#
?
Aug 30, 2018 21:17
|
|
|
The way we handled early code freezes was to create a new branch just for internal release every week. One person managed releasing from that branch. Everyone else was able to just keep working like usual. It's relatively painless with a good versioning system. We used git, but I'd expect SVN to work just as well. We also used 2 week sprints. They didn't hurt, but they were mostly a way to self-track what the next thing we were going to work on so we didn't have to pull from a huge heap after every task, just our little pool. Management never tried to get us to not work if we finished early or anything crazy like that.
|
|
#
?
Aug 30, 2018 21:23
|
|
|
Carbon dioxide posted:- Poster still blames scrum, giving fresh developers who want to give agile (the real kind, not the led-by-management kind) a try a sour taste about it from the start. Nothing wrong with agile but scrum is loving poo poo and you won't convince me otherwise.
|
|
#
?
Aug 30, 2018 21:45
|
|
|
Scrum predates agile.
|
|
#
?
Aug 30, 2018 21:48
|
|
|
Rubellavator posted:I often feel like every reporting metric management uses is wrong. Vague and noncommittal responses are my dearest friends.
|
|
#
?
Aug 30, 2018 22:04
|
|
|
Bongo Bill posted:Scrum predates agile. scrum was invented in the mid-90's, agile manifesto was 2001. i don't think there is a real relationship between agile and scrum - the answers i've gottten on the relations between scrum/agile range from "scrum is a subset of agile" or "scrum is an implementation of agile", but these fail the sniff test as they are anachronisms. if we evaluate the goals of scrum vs. the agile manifesto, if anything, they are either opposed or unrelated (e.g. scrum is a process/tool, whereas agile values individuals and interactions.) agile is being used as a smokescreen by this scrum bullshit.
|
|
#
?
Aug 30, 2018 23:29
|
|
|
comedyblissoption posted:I've personally had the displeasure of working under a milder version of this failure. If you finished working on stuff early in a sprint, you were encouraged to find a tiny (often low value) story you could squeeze into the sprint instead of getting started early on the next big thing. We'd miss deadlines working on stupid bullshit instead of high priority items because of this foolishness. Using sprints as short term deadlines also goes against the intention. Failing to meet the sprint commitment should be seen as a failure of estimation, not of delivery. That's the one you see misinterpreted/abused the most though because it's the easiest to measure for management. I don't do scrum anymore and I don't know why you wouldn't be allowed to get a head start on the higher priority items though 
|
|
#
?
Aug 30, 2018 23:44
|
|
|
I like the GROWS method, made & trademarked by some of the agile manifesto authors because they didn't want people to gently caress around with it, aligns agile with the business process maturity model. https://growsmethod.com/ The site's a little hard to take seriously but it's all there.
|
|
#
?
Aug 30, 2018 23:53
|
|
|
comedyblissoption posted:The entire point of points is to help you estimate. If you start doing things that hurt your ability to estimate, then you're going to be worse at estimating. It's very hard, especially for projects that are on-going, to give a complete estimate of all the work you are going to do relating to that project. That's pretty much the reason we use an iterative process. When you only assign points to and track work related to features, that is what you are doing. You are saying "I believe this project is complete, there will be no follow-ups, so there is no point (  ) trying to plan for and prioritizing follow-ups."When you make a point estimate, on a feature or on a bug, you are not saying this is how much effort this will take. Rather, you're saying this is how much effort I am prepared to give, in the context of other competing priorities. If what you think is a small bug ends up exploding in scope, you have the option to timebox it so you can work on your other priorities, or to push other priorities out of the sprint to continue working on it. If you don't assign points to bugs, you will either never work on bugs, or overwork yourself by trying to do all your other tasks and bugs. Neither is a good process. Bongo Bill posted:If you point bugs, it becomes possible to increase velocity by writing worse code so that more bugs are opened and less time is available to spend on features. Lots of questionable things in your post but I just want to call out this one (especially cause comedyblissoption hinted at it too with "velocity credits"). You shouldn't be held to any specific velocity measure, so there is no reason to try to game your velocity measurements. Points and velocity are only for current and future planning, so inflating or deflating your numbers just makes your team under- or overworked.
|
|
#
?
Aug 31, 2018 00:04
|
|
|
Pie Colony posted:Lots of questionable things in your post but I just want to call out this one (especially cause comedyblissoption hinted at it too with "velocity credits"). You shouldn't be held to any specific velocity measure, so there is no reason to try to game your velocity measurements. Points and velocity are only for current and future planning, so inflating or deflating your numbers just makes your team under- or overworked. All of this is true. However, teams using scrum tend to suffer from other problems, including being subject to outside pressure to make the velocity number go up. Given this unfortunate condition, it's better if they structure themselves internally so that doing the right thing rather than the wrong thing causes the bullshit to become prettier.
|
|
#
?
Aug 31, 2018 00:23
|
|
|
Janitor Prime posted:Rightly so, because that's the kind of hellscape found over and over again in countless orgs. I think at this point horrible misinterpretations of scrum outnumber the ones that get right by a significant margin.
|
|
#
?
Aug 31, 2018 01:06
|
|
|
I like when discussions like this happen because it gives me hope that we'll all learn a little from each others' stories and maybe get better at this process poo poo eventually.
|
|
#
?
Aug 31, 2018 01:44
|
|
|
Carbon dioxide posted:Ah, I see it's time of one of THESE posts again. A true classic in this thread. ah yes, the "no true scrum" argument
|
|
#
?
Aug 31, 2018 01:55
|
|
|
Our PM is getting us to do story point estimations now because we have drastically overcommitted for the past few sprints. Last job they wanted us to do points so they could rank our performance against each other which was a little hosed.
|
|
#
?
Aug 31, 2018 02:03
|
|
|
Oh, yeah, my previous job was like that, using 'scrum' points system as one of the ways to measure performance. Then they realized that every team was pointing things differently, so now all points were equal to 1 'average Joe dev' manhour.  I pivoted out of there shortly afterward.
|
|
#
?
Aug 31, 2018 02:13
|
|
|
CPColin posted:I like when discussions like this happen because it gives me hope that we'll all learn a little from each others' stories and maybe get better at this process poo poo eventually. The way it gets better is by teams figuring out the process that works for them rather than shoehorning every team into a rigid interpretation of the one true process
|
|
#
?
Aug 31, 2018 02:23
|
|
|
Jose Valasquez posted:The way it gets better is by teams figuring out the process that works for them rather than shoehorning every team into a rigid interpretation of the one true process Exactly. It becomes agile when after each retrospective (whether that's part of a scrum sprint or not) a team, on its own, without interference from management, is able to change the parts of the process that don't work and keep and improve on those that do. At my job we use 'scrum' in the sense that we estimate story points (that have no meaning outside of the team), and use those to plan sprints so that we can focus on things instead of being interrupted every second by stuff from sales or whatever. The scrum guide really only says some things about the high-over process. It doesn't go into detail about a lot of stuff, mostly because that's left up to the users of the method to fill in. This is the sense in which it's agile. A good scrum team uses the parts of scrum that turn out to work for them, drops the parts that don't, and add parts from other project methodologies or from their own invention that add value to their process. And they certainly don't let themselves be pushed into some straightjacket unchangeable scrum process by management who don't know what they're doing. If you're in a company that does act like that, it might be time to go find another place of work. There's plenty of companies who do get it right. A good metric is whether they value long-term innovation over short-term sales figures (to a point, of course. They still have to be able to pay your salary).
|
|
#
?
Aug 31, 2018 07:10
|
|
|
|
| # ? May 9, 2024 21:26 |
|
|
Scrum is bad, but not as bad as most implementations of "Scrum" make it look.
|
|
#
?
Aug 31, 2018 07:24
|
|
