|
ThePopeOfFun posted:Sprint planning meetings seem like they could be great if everyone had a decade or more of experience in the code base. it's always fun to be asked to estimate work on a part of the codebase that you've never personally dealt with and then be held to it rigidly
|
#
?
Jun 7, 2023 04:39
|
|
|
|
| # ? May 10, 2024 02:52 |
|
|
I enjoy being asked to estimate work that hasn't been scoped yet and could be anywhere from one day to one year depending on what the one sentence description actually means.
|
|
#
?
Jun 7, 2023 05:15
|
|
|
My work asks for such an estimate during the meeting where the customer has just described what they wanted. While the customer is still there listening. I keep refusing to give any answers other than, "I'll have to look at it."
|
|
#
?
Jun 7, 2023 05:25
|
|
|
Scrum is what you do when management wants you to "be agile" but doesn't want you to have autonomy. Everything about it sucks because it all proceeds from that contradiction. The most reliable way to forecast when a feature will be complete is to let the team work in a consistent and sustainable way, measure their pace, and extrapolate from that. This requires trust and forbearance, and that makes it anathema to authoritarian management styles, which tends to select for promotion people who prefer to feel in control than to succeed.
|
|
#
?
Jun 7, 2023 06:04
|
|
|
Our team is, 4 business people, 1 pm, 1 tester and 2 devs. Sprints just seem to add downtime, because of running out of tasks. Since business stories like having meetings informing different departments of our new features etc are included points done per sprint has no relationship with dev work. At least my philosophy is to skip any meeting where I don't know why I should be there or where I don't feel like it gives me anything. Works so far, but I suspect people find me a bit grumpy. This org is so large you could just accept every meeting you get invited to and not do any actual work while still looking super busy.
|
|
#
?
Jun 7, 2023 06:27
|
|
|
prom candy posted:As far as I can tell it's all about planning and projections on the business side. Managers need to tell their managers what's going to be done in 3 months so that those managers can tell their managers. But like...can't you do that without the sprint system? I dunno, maybe I'm just not fully on board with what constitutes scrum or agile or whatever, but: Breaking work into tasks makes sense Developing requirements for those tasks makes sense (something my current team doesn't do and boy do we waste time because of it) Estimating how long something will take (to some reasonable degree) makes some level of sense, although it's certainly not easy. Sprints = ??? Like, why not just have a weekly update on 'here's what got done, here's what'll be done next' - groom your backlog, tally up the time estimates, add 50%, delivery date? That doesn't even necessarily need to be a meeting as long as your tasks get moved along the kanban as they progress.
|
|
#
?
Jun 7, 2023 07:32
|
|
|
CPColin posted:And I'm pretty sure all three of those Aren't Scrum™ I'm fairly confident #2 is absolutely scrum.
|
|
#
?
Jun 7, 2023 07:34
|
|
|
Okay, sure, you're allowed to add things mid-sprint, but
|
|
#
?
Jun 7, 2023 07:41
|
|
|
Falcon2001 posted:But like...can't you do that without the sprint system? I dunno, maybe I'm just not fully on board with what constitutes scrum or agile or whatever, but:
With that said, I've rarely seen sprints done in a way that gives these or any other clear benefits.
|
|
#
?
Jun 7, 2023 09:32
|
|
|
My understanding is that sprints were originally a technique for managing business stakeholders. Highly involved, interfering types are only supposed to be able to change priority at the sprint boundaries, so that some work can get fully completed instead of being left half-done. For less involved folk, having regular deliverables is supposed to provide opportunities for feedback and course correction, to make sure that devs don't spend months delivering on a spec that isn't actually useful. In reality of course, this whole angle of agile - getting autonomous dev teams involved in business tactics - tends to get ignored entirely. Instead it gets used as a means to having more sticks to beat devs with, and the actual value of work getting done is missed.
|
|
#
?
Jun 7, 2023 10:23
|
|
|
Every time I've looked into how it's supposed to work, the idea seems to be that while estimating time directly is very difficult, and estimating complexity or scale doesn't translate directly into time, if you do the latter then teams tend towards relatively consistent numbers of points completed per sprint anyway. It's also supposed to be an indicator of when something is just too big, because you might score something as a 5 but when broken into two smaller chunks the overall complexity is reduced so they might both get scored 2. This doesn't fit in with deadlines directly, but it should be a way to at least say what work is expected to be done in the current or next sprint. In practice though, I'm pretty sure the one thing you're not supposed to do is equate 1 point = 1 day of work, but in every case I've ever seen that happens anyway. When this happens even the theoretical purpose of sprints and points no longer applies, you end up with all the same problems of traditional deadlines except now there's effectively a mini-deadline attached to every story so planning is now a negotiation, with all the politics and overhead that implies. My team is the only one here doing kanban, but we also only have 3 people and very few people understand what we do so it's not catching on elsewhere.
|
|
#
?
Jun 7, 2023 11:20
|
|
|
My team claims 1 point = 1 day but then we also do fibonacci numbers... so I guess no task should ever take 4 days? Also, if the team has completed an average of 40 points the last 3 sprints our manager makes sure the team takes 40 points worth of work, but then gets slightly annoyed when we miss even though using the average as a target means we'd only hit the target 50% of the time. I have a background in manufacturing quality assurance so I know a control chart and how to measure a process like the back of my hand but trying to change anything is 'gaming the system'. Agile sucks rear end. Kanban for life.
|
|
#
?
Jun 7, 2023 12:49
|
|
|
Falcon2001 posted:I wish someone could explain to me what the benefit of scrum is supposed to be (over a simple Kanban priority system), as I've never worked in an environment where we weren't randomized enough the idea of 'commit to what you're doing for the next two weeks' is just ridiculous. Maybe it's just a different team setup thing? Scrum came out as a reaction to dev teams being pulled in many directions at once, like situations where VPs, sales, various project managers etc would all walk up to your desk and demand status updates or expect work done immediately. The point of the PM role was to centralise decision making on that to take those fights away from the dev team. Locked sprint length with capacity planning etc was meant to give teams certainty of priority for a set time. Ideally it was to force stakeholders to commit to priorities, not hold the team accountable. You can see this a bit in the literature that the sprint length should be decided at the start of the project around how often the stakeholders would like an escape hatch if they need to change direction. If your team and organisation are mature enough to deal with kanban there’s no on paper reason scrum would necessarily be better. It was intended to improve places that were even worse.
|
|
#
?
Jun 7, 2023 13:02
|
|
|
I was wrestling with something here just recently and might as well insert myself here. Planning and estimation is a major part of any of these processes, but it's not like you can't do planning and estimation without agile. They are independent of each other. It could be a cowboy coding shop and you could still plan and estimate. I suppose it would be antithetical to a hero culture place though; that sure as hell was my experience. As for point sizes: I started with powers of two and that seems to be a minority. It would not stop me from from using whatever number if I knew better. If a story was probably going to take just a few days (disregarding point value here) and you happened to analyze it deeply enough that it's, like, 7 points, the gently caress it. You are an adult. Throwing out oddball numbers was a simple way for me to test how dogmatic other people were. I was working with one team that did 1 point=1 week. I was breaking down work finer than that for a few years so I had a bunch of zero point stuff. If they had a dogmatic management, I would have been closing 4+ stories a sprint but zero points.
|
|
#
?
Jun 7, 2023 14:12
|
|
|
What I like about agile and scrum is that, if the company buys into it in a big way, front line managers can learn to use it as a weapon to protect their team.
|
|
#
?
Jun 7, 2023 15:04
|
|
|
Points are arbitrary; the utility is in requiring everyone on the team to read and discuss the story and reach a consensus about what is expected to be done, and asking everyone to assign a number to it is simply a trick to force participants to reveal whether they have wildly different interpretations of the task. If you have the discipline to hold that review without producing an otherwise useless number, then you don't need to estimate, but a lot of teams don't have that. If you're holding estimation sessions where people are totally checked out, you're doing it backwards and probably have many other problems. The reason for the indirection between points and time is to keep the emphasis on describing the task itself, which is the same regardless of whether it is done by the fastest or the slowest member of the team. Converting between points and time is trivial for the entire team, since fluctuations in accuracy (whether caused by misunderstandings, differences in individual aptitude, or anything else) will basically cancel out, giving a stable average. The reason why points are unnecessary for forecasting is because the average size of a story will also remain stable over time. All of this, however, depends on the team being permitted to work at a natural pace, without being pressured into haste or overwork in order to reach an arbitrary target or commitment. No matter what you might gain by scrambling in that way, it will distort the consistency of the team's productivity, and therefore defeat the ostensible purpose of being able to predict and plan around the question of "How long will it take to get this?" The minute you get people wondering about "How to deliver more points in a sprint," all that goes out the window. You want something faster? Increase its priority. You want everything faster? Invest time into improving the skill level of the team.
|
|
#
?
Jun 7, 2023 15:11
|
|
|
I want everything done cheap, fast, and good and if you miss that goal, you're all fired!!
|
|
#
?
Jun 7, 2023 16:15
|
|
|
Good news is firing people makes things cheaper right way and the measurements don't get worse until later
|
|
#
?
Jun 7, 2023 16:43
|
|
|
This organization is totally ineffective, good thing we fired them all
|
|
#
?
Jun 7, 2023 16:44
|
|
|
I'm spectating this thread from the auto industry and deeply need an explanation of what is called "kanban" in the software field and how it works. Integration sends you an empty box back when they run out of bubblesort implementations and then the coders fill it back up?
|
|
#
?
Jun 7, 2023 17:27
|
|
|
shame on an IGA posted:I'm spectating this thread from the auto industry and deeply need an explanation of what is called "kanban" in the software field and how it works. Kanban in a programming context has just one main thing in common with kanban as invented for manufacturing: the kanban board itself. Represent the work in a series of columns, each one representing a stage of the process: design, ready for implementation, implementation, ready for testing, testing, etc. (these are not the actual names of the columns, just descriptions). Each feature is in the column reflecting its current status, listed in the order that it needs to be done in. A programmer takes the top item from "ready for implementation," moves it to "implementation" to indicate they're working on it, moves it to "ready for testing" when they're done. A tester picks the top item from "ready for testing," moves it into "testing" to indicate they're working on it, and so on down the line. Send it back if there's a problem. That board represents the overall state of the project at a glance. Importantly, as compared to other ways of structuring programming work, that's it. There's no element of time, no sprints, no deadlines. It prescribes no particular means for figuring out what to build in what order, what meetings to have when, or how to come up with a long-term strategy. It purely describes the tasks to be done and their relative priority and dependencies. Everything else is up to the team to come up with something that works for them.
|
|
#
?
Jun 7, 2023 17:58
|
|
|
Well, one other element of Kanban you're supposed to have is work-in-progress limits. So if the team is limited to 4 items in development and there are already 4 in that column, try to help someone out or focus on moving tasks from another column (e.g. code review). I see this would be useful for one of my teams that has a problem of semi-abandoned PRs but I haven't been able to get it to stick.
|
|
#
?
Jun 7, 2023 18:50
|
|
|
At a minimum, in orthodox Kanban there's also a ton of metrics you're supposed to track and use to tweak the process. There's plenty of meetings that are semi-analagous to Scrum meetings too. A lot of teams who say they use Kanban just mean they have a board and don't want to be bothered with a lot of agile stuff beyond that, which is fine. thotsky fucked around with this message at 20:38 on Jun 7, 2023 |
|
#
?
Jun 7, 2023 20:36
|
|
|
Most “serious” pointing I’ve been involved with: * You do 1-2-3-point and then people raise fingers, in an intent to be independent numbers. * if it isn’t unanimous, people have to argue for their pointing. * you repoint until it is unanimous In theory this identified people who didn’t understand the story. In practice those people just agreed to the majority and still didn’t understand the story. Also it doesn’t work at all when you are all remote.
|
|
#
?
Jun 8, 2023 13:17
|
|
|
My kids have seen me doing the "1-2-3 point" exercise on zoom and it prompted a lot of questions about what I actually do at work all day
|
|
#
?
Jun 8, 2023 13:34
|
|
|
can we please just say "hours" or "days"
|
|
#
?
Jun 8, 2023 15:22
|
|
|
Fellatio del Toro posted:can we please just say "hours" or "days" No, because that's dependent on which person is doing the work. You really don't want to be measuring individual performance in that way, only the team's performance. For that reason, you want a value that describes the work that needs to be done irrespective of which team member ends up doing it.
|
|
#
?
Jun 8, 2023 15:58
|
|
|
Fellatio del Toro posted:can we please just say "hours" or "days" The fact that we can't if we want to actually plan (as opposed to pretend planning), is the whole point behind giving stories points and measuring velocity.
|
|
#
?
Jun 8, 2023 16:05
|
|
|
Bongo Bill posted:For that reason, you want a value that describes the work that needs to be done irrespective of which team member ends up doing it. I get where people are coming from with this, but my entire career has had a lot of non-fungible work so I rarely see this in practice. I am just surprised that it may be a majority situation.
|
|
#
?
Jun 8, 2023 16:07
|
|
|
smackfu posted:Also it doesn’t work at all when you are all remote. I'd say it works better... Use the chat box and change it to 1-2-3-enter.
|
|
#
?
Jun 8, 2023 18:13
|
|
|
Bongo Bill posted:No, because that's dependent on which person is doing the work. You really don't want to be measuring individual performance in that way, only the team's performance. For that reason, you want a value that describes the work that needs to be done irrespective of which team member ends up doing it. That just isn't a thing unless your entire team has the exact same skillset and just work at different speeds or something. One task may take person 1 a week and person 2 a day, while another task is the other way around.
|
|
#
?
Jun 8, 2023 21:06
|
|
|
smackfu posted:Most “serious” pointing I’ve been involved with: Is this the same thing as planning poker?
|
|
#
?
Jun 8, 2023 21:10
|
|
|
Plorkyeran posted:That just isn't a thing unless your entire team has the exact same skillset and just work at different speeds or something. One task may take person 1 a week and person 2 a day, while another task is the other way around. Sure, but you want to try to describe the general complexity/difficulty of the task, in time unit independent numbers. The idea is that your team velocity is relatively consistent, and the relative difficulty of the tasks is not highly variable based on who is doing it. As a result, even though X only does 6 points per sprint and Y does 30, you still schedule roughly 36 points regardless of which tasks X chooses. Giving difficulty in hours / days is like giving difficulty in LoC; please, do not.
|
|
#
?
Jun 8, 2023 21:24
|
|
|
Pedestrian Xing posted:Is this the same thing as planning poker? Yes
|
|
#
?
Jun 8, 2023 21:30
|
|
|
Points are not hours, but inevitably people make the connection that 1 point is 1 day. They should just use letters instead. We can do 3 "A" stories or 6 "B" stories or 12 "C" stories in a sprint. Mix and match as needed. I'm sure this would clear up the confusion.
|
|
#
?
Jun 8, 2023 21:34
|
|
|
Jen heir rick posted:Points are not hours, but inevitably people make the connection that 1 point is 1 day. They should just use letters instead. We can do 3 "A" stories or 6 "B" stories or 12 "C" stories in a sprint. Mix and match as needed. I'm sure this would clear up the confusion. T shirt sizes!
|
|
#
?
Jun 8, 2023 21:41
|
|
|
We use animals. Our stories are mouse, cat, dog, cougar, horse, giraffe, elephant. Mouse is 1 hour, cat is 2 hours, dog is 3 hours, cougar is 5 hours, horse is 8 hours, giraffe is 13 hours, and elephant is 21 hours. Also I know you all said in planning poker that this story was elephant but management is really on me to get it shipped by next week so can we just change it to giraffe? And anyway I don't even see what's so complicated about it that it's going to take 21 hou – sorry, I mean, what's so complicated about it that's it going to take elephant hours.
|
|
#
?
Jun 8, 2023 21:58
|
|
|
Pedestrian Xing posted:Is this the same thing as planning poker? Heh, didn’t realize there was a version with actual cards.
|
|
#
?
Jun 8, 2023 23:52
|
|
|
One of the things I've noticed with story points in particular is that it can lead people into a mentality of 'scoring', of pushing for more points, regardless of the work being done. Business types always want stuff faster, but thinking of the work in terms of points scored can strip away any notion of how useful the work is. At a previous job, the engineering managers would hold a weekly status meeting looking at the burndown charts for the 6 teams, then they'd compile one combined chart saying "this sprint, we completed 268 story points, with 54 points carried over". We'd end up having to scramble round for work to look busy with often fixing or replacing the poo poo we'd done previous sprint, and there was a big culture of people staying late to avoid that carry-over. In fact, after I left I heard they'd restructured the department around football/soccer metaphors, so teams were 'squads', sprints were 'cups' and everyone competed on the number of points. Absolute madness.
|
|
#
?
Jun 9, 2023 00:21
|
|
|
|
| # ? May 10, 2024 02:52 |
|
|
GordonTheDeadFish posted:One of the things I've noticed with story points in particular is that it can lead people into a mentality of 'scoring', of pushing for more points, regardless of the work being done. Business types always want stuff faster, but thinking of the work in terms of points scored can strip away any notion of how useful the work is. we use product squads, and the worst performing ones in terms of developer happiness (and self-perceived productivity) are the ones where the Product Manager plays story point accounting games and get all freaked out when stories carry over. they're also usually the same teams where the PMs will change direction constantly, offload their job duties onto the devs, and leave every day at 5pm while getting torqued that the devs "aren't working hard enough". drives me nuts.
|
|
#
?
Jun 9, 2023 01:00
|
|
