|
Pollyanna posted:so we just plan the sum total of the tickets' hours to be (2 weeks/sprint * 40 hrs/week * 2 people per ticket) = 160hrs. This is awful and wrong. Do either of you go to meetings? Do you use the bathroom? Do you take breaks? Assuming that a developer works on specific assigned tasks for 8 hours out of every day is insane. Put real estimates on tasks, don't try to make everything total 160 hours.
|
#
?
Mar 8, 2016 14:42
|
|
|
|
| # ? May 2, 2024 05:21 |
|
|
Ithaqua posted:This is awful and wrong. Do either of you go to meetings? Do you use the bathroom? Do you take breaks? Adding to this: If you think it will take 160 hours, double it.
|
|
#
?
Mar 8, 2016 14:49
|
|
|
In case anybody is interested, this is the e-mail we get at my office when we haven't logged 8 hours every day: (this is then followed by a list of the people who didn't log all their hours)
|
|
#
?
Mar 8, 2016 14:50
|
|
|
Illegal Move posted:In case anybody is interested, this is the e-mail we get at my office when we haven't logged 8 hours every day: Holy poo poo I would just put "lol" in the missing fields. Thank god I'm WFH and Salaried. I gently caress off for around 2 hours a day, but am more productive at home than when I am at the office.
|
|
#
?
Mar 8, 2016 14:51
|
|
|
Having to put a lot of effort in to time tracking was one of the big reasons I didn't like my last job. It's not so bad when there's not a lot of pressure to cover the whole day and it's more of a way of seeing how long things take, but once you start adding the pressure from management to have the full time it starts to really bum you out.
|
|
#
?
Mar 8, 2016 15:05
|
|
|
Illegal Move posted:In case anybody is interested, this is the e-mail we get at my office when we haven't logged 8 hours every day: "It has to be agreed with supervisor", because copyediting the template you're going to Glengarry Glen Ross people with is just too hard.
|
|
#
?
Mar 8, 2016 17:52
|
|
|
Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement?
|
|
#
?
Mar 8, 2016 18:42
|
|
|
I hadn't heard of it before now, but I know one of the main reasons my team switched from Scrum to Kanban was because we all (mostly me) complained so much during sprint planning that certain issues were impossible to estimate. We always had stuff like "figure out how we can use technology X" and "tear down this architecture we've been using for years and build a new one." My answer was always, "I won't know until I get in there." We finally started doing stuff like agreeing to spent X hours/days on initial investigation and filing follow-ups, as necessary. The better fix was to use Kanban, where the most important stuff is always at the top and we can abort out of it if everything starts to snowball.
|
|
#
?
Mar 8, 2016 19:05
|
|
|
CPColin posted:I hadn't heard of it before now, but I know one of the main reasons my team switched from Scrum to Kanban was because we all (mostly me) complained so much during sprint planning that certain issues were impossible to estimate. We always had stuff like "figure out how we can use technology X" and "tear down this architecture we've been using for years and build a new one." My answer was always, "I won't know until I get in there." "Tear down this architecture we've been using for years" is way too big to estimate, it should not be a user story.
|
|
#
?
Mar 8, 2016 19:29
|
|
|
Ithaqua posted:"Tear down this architecture we've been using for years" is way too big to estimate, it should not be a user story. Yeah, that sounds like a problem with how you guys were doing things and not a problem with the methodology.
|
|
#
?
Mar 8, 2016 19:43
|
|
|
No poo poo! Edit: Even when we started breaking those things down into "investigate what we want to do, investigate how to do it, do it" series of issues, it wouldn't fit into sprints, because we couldn't hope to estimate steps two and three before step one was done. Fortunately, the people running the meetings finally gave up arguing with us when we refused to give numbers. CPColin fucked around with this message at 20:23 on Mar 8, 2016 |
|
#
?
Mar 8, 2016 19:56
|
|
|
Here's my timesheet nag email: Missing Timesheets for [ME] Minimum hours per day expected: 8.00 Hours input for 04/03/16 6.25 Hours input for 03/03/16 7.25 Hours input for 02/03/16 8.25 Hours input for 01/03/16 8.50 Hours input for 29/02/16 7.50 We have time fields attached to our task tracker thing - works fine for support / investigation jobs, but it's totally useless for when you're just working on projects. On the bright side we've written a bunch of code to extend the timesheet tool and make it really easy to just go '2 hrs admin 2 hrs checking emails 5 days a week' to fill in all the other time. Agency work and doing dev for 30 clients at once has its own hilarious set of impediments for developers - I always laugh when we're asked to estimate how long investigating a problem will take before beginning to investigate it so they can get into fights with clients over approving 2 hrs of time.
|
|
#
?
Mar 8, 2016 21:09
|
|
|
Ithaqua posted:This is awful and wrong. Do either of you go to meetings? Do you use the bathroom? Do you take breaks? I was told that was more or less what the project managers expected in term of hours logging.  It's not how I would do it at all, but I've given up on fighting it - I can't help them change their behavior by myself, especially since the company is a glacier of a dinosaur w/r/t project management policy. They have to be the ones to change, and they won't change within the decade.I can say so much more about this company and its weirdass practices, but I've given out enough identifying information as is.
|
|
#
?
Mar 9, 2016 00:17
|
|
|
Ithaqua posted:"Tear down this architecture we've been using for years" is way too big to estimate, it should not be a user story. Right; the proper formatting is: "As a developer, I want to tear down this architecture we've been using for years, so that I will no longer wish for the sweet embrace of death." edit: Sounds like an "8"
|
|
#
?
Mar 9, 2016 02:43
|
|
|
Ithaqua posted:This is awful and wrong. Do either of you go to meetings? Do you use the bathroom? Do you take breaks? ratbert90 posted:Adding to this: If you think it will take 160 hours, double it. Take your estimated duration of the task, A Multiply A by up to 1.25 depending on how busy the office feels this quarter, giving you B. Take B and double it, giving you C. If you aren't doing the task yourself, times C by 1.25x again, giving you D. A = your optimistic guess B = all your interruptions C = because you can't guess for poo poo D = because you know more than others If you work in an agency and you look at D and you go "oh poo poo, that's high" then you can remove up to 30% of the original time in A. Never more. If you don't work at an agency, add another 10%. Also, never provide an estimate you wouldn't be happy to give to a coworker you like. Inflate the estimate further if you think it would piss someone else off. xiw posted:Agency work and doing dev for 30 clients at once has its own hilarious set of impediments for developers - I always laugh when we're asked to estimate how long investigating a problem will take before beginning to investigate it so they can get into fights with clients over approving 2 hrs of time. My advice is to get the OK from the client for 30 minutes of investigative work, and you can refine your estimate each time. That way you can give them a better idea of what the problem is and how much longer you need, even if you can't estimate on the fix. v1nce fucked around with this message at 05:52 on Mar 9, 2016 |
|
#
?
Mar 9, 2016 05:49
|
|
|
Our way of handling that is just a 2 point spike. The acceptance criteria of any spike is that the user stories to do the actual work are refined, and it's time boxed to usually three days. Anything scoped over 5 points is an admission that we need to break it up better so yah that would be an 8 with us with a two pointer to fix it.
|
|
#
?
Mar 9, 2016 05:51
|
|
|
v1nce posted:Take your estimated duration of the task, A 10,000% this. It takes a while working for consultancies to figure this out. Everyone should take it to heart.
|
|
#
?
Mar 9, 2016 07:59
|
|
|
I've found some basic heuristics that seem to work well for us at the moment during sprint planning: - Any story should be divided up into tasks that can easily be done by one developer in one day. The exact number of hours doesn't matter that much, but if you're not able to do this, you probably don't know enough about the story to finish it. - A story containing more than 10 tasks is suspicious and should probably be split up into two stories so that they can be tested separately. I'm sympathetic towards the #noestimates thing to the extend that, if you can get away with doing less estimation, by all means do it
|
|
#
?
Mar 9, 2016 09:08
|
|
|
Forward: I'm using the word "task" here when what I mean is "story." We had a sprint recently that we did pretty poorly on in terms of delivery, for a few reasons: 1) We didn't know enough about the existing code for one of the tasks. I had taken a brief look before planning and thought it would take a certain degree of effort, but once I really started digging in to the existing code, there were a lot of little gotchas and branching paths and otherwise things I had to account for, and it is closer to twice as much effort as I expected. 2) We didn't leave any room for bullshit. Meaning, emergencies, outages, and questions/problems from Support that we have to go digging for. Something happens every week and we just need to leave room in the sprint to account for it; when we've done that in the past it's worked out really well. 3) General overcommitment by the team. I said right out that <set of tasks> was my entire sprint, that I was personally full up (I'm basically the only one who works on a particular layer in our team). Team then takes more tasks, some of which require my contribution. I mostly blame our product owner for 2 and 3. His refrain in planning is "I want you to take more of these tasks." We need to start telling him to pound sand but I would like it if he trusted us to not under-commit out of laziness. #1 is the big bugbear though. When we figure out a task is significantly larger than we expect, we should get back with the PO and work out how to break it down and which pieces should get done this sprint and which can be put off. Either that or we don't start a task until we understand it and the relevant systems well enough to estimate and partition it more confidently. Which would require committing to fewer tasks so that we could perform said investigation (or make investigation tasks which go against the whole "deliverable" goal of a sprint item).
|
|
#
?
Mar 9, 2016 10:19
|
|
|
Pollyanna posted:I was told that was more or less what the project managers expected in term of hours logging. Your project managers are idiots. Take this as a chance to learn how to better deal with idiots, maybe. I could see if there were big problems with productivity they might want you to account for everything, but still, assuming 8 actually productive hours on tasks is dumb. When do meetings happen? Are meetings stories in your sprints? How would that even work? Is taking a bathroom break a story? "As a human, I need to poop so that I can continue to live." My previous employer assumed something like 4-6 hours/day of "heads down" time (be that coding, creating diagrams, researching new tools) with the rest being eaten up by random poo poo like meetings, people bugging you for stuff, pooping, etc. The estimate of "heads down" time would change based on the level - junior devs were expected to be closer to 6 hours, senior were considered lucky if they got 4. metztli fucked around with this message at 14:20 on Mar 9, 2016 |
|
#
?
Mar 9, 2016 14:16
|
|
|
8 hours is probably for the beancounters. They're expensing time against projects so they can depreciate development costs. The accountants probably have a bullshit number to use for each hour of developer time that includes overhead (benefits, rent, etc.) and they multiple that by hours on the project to arrive at project cost and that bullshit hourly cost assumes 40 hours. A better way to do it is to do a ratio. (this guy spent 2/3 of his time on project A so we multiple his cost....) but accountants seem to like the easier per-hour method.
|
|
#
?
Mar 9, 2016 14:28
|
|
|
I think they're idiots too. They also are wayyy over my head and about 1.5-2 hours away by car at the main corporate office, and the company's culture basically hasn't changed since 1920. There's nothing I can do about it. I certainly push back when I get the chance - lord knows I'll talk someone's ear off about how badly they're doing things - but I don't assume I'll get anywhere, and I kind of want to keep my job so I don't wanna piss them off. I'm really, really unhappy with how we scoped our work for this sprint. Especially since the majority of it requires research via meetings with the individual product owners, most of which are like "can we schedule a meeting for <three days later>?" and then postpone it for another two. So, it's not just badly estimated - most of that time estimate is downtime because MEETINGS. I'm spending my time on self-education as a way to offset that, and so I don't seem like I'm slacking. Let's not make this into the Pollyanna Power Hour again. Point is after this sprint, I'm gonna ream them on their awful process. Also the day of every sprint planning we have a 3-hour demo meeting at 9:30 where the product owners (not developers) demo the stuff that happened this sprint. Isn't that fuckin' crazy?
|
|
#
?
Mar 9, 2016 16:33
|
|
|
Sometimes I think my job is a little goofy when it comes to their agile implementation, then I read this thread and feel better. Our agile isn't exactly making things better, but at least it's not actively making them worse.
|
|
#
?
Mar 9, 2016 16:37
|
|
|
In my opinion software development is virtually impossible to estimate accurately, because in order to accurately estimate how long it takes to build something you need to have done it before, and if you've built something before in software why aren't you just re-using that code? Hence everything you build tends to be novel, at least to you, otherwise you wouldn't be building it. Not only that, this is probably MORE true the better your other development practices are, because you'll tend to develop in a more generic way that's more amenable to re-use.
|
|
#
?
Mar 9, 2016 18:46
|
|
|
Cicero posted:In my opinion software development is virtually impossible to estimate accurately, because in order to accurately estimate how long it takes to build something you need to have done it before, and if you've built something before in software why aren't you just re-using that code? Hence everything you build tends to be novel, at least to you, otherwise you wouldn't be building it. Not only that, this is probably MORE true the better your other development practices are, because you'll tend to develop in a more generic way that's more amenable to re-use. It's not always possible to reuse code if you're developing proprietary poo poo for different clients  or if there are some insane little differences that the customer absolutely must have because. As with point estimates I find hourly estimates are easy if the complexity is known like slamming out a couple of methods and database poo poo. Sure some copy paste, but not the same code.
|
|
#
?
Mar 9, 2016 18:54
|
|
|
spacebard posted:It's not always possible to reuse code if you're developing proprietary poo poo for different clients The point remains. IF you are somehow quoted to do the EXACT SAME THING over again, you should be able to give a fairly accurate answer for the second time, since all you are doing is typing it all over again. There is no discovery phase. This rarely happens though, as no matter what, requirements are usually significantly different, even between very similar sounding situations.
|
|
#
?
Mar 9, 2016 19:24
|
|
|
It's also impossible to, for example, estimate integrating systems into other systems that 1. you aren't allowed access to and 2. don't know the details of. Especially when they're like "this shouldn't take you more than one sprint" and subsequently cockblock you on meetings and security access grants and poo poo. Developers need agency and power in order to just loving get things done.
|
|
#
?
Mar 9, 2016 20:47
|
|
|
I'm a contractor at a very large company with a lot of process around internal requests and such, and they hired a team from a NYC agile company who are used to working with startups with no rules and boy do they hate this large company so much. I get a weekly email rant complaining about how they have to wait on other people and they don't understand "why it has to be this way."
|
|
#
?
Mar 10, 2016 14:02
|
|
|
You are probably trying to make the point "lol, entitled shits", but not understanding why a process is there is a valid complaint.  Of course, that depends on the tone of the rants more than anything else, but.
|
|
#
?
Mar 10, 2016 14:28
|
|
|
HardDisk posted:You are probably trying to make the point "lol, entitled shits", but not understanding why a process is there is a valid complaint. I just take the mounds of process as a reason to try and be less pressured and hurried. If it's gonna take a while, I might as well let my blood pressure benefit from it.
|
|
#
?
Mar 10, 2016 15:09
|
|
|
Oh yeah, I recognize I have some Stockholm Syndrome from working in large companies for a long time. At heart it's just a bad culture clash and I just wish I wasn't in the middle of it. It's amazing how much time an agile team can spend on chores without making much progress though.
|
|
#
?
Mar 10, 2016 15:14
|
|
|
Pollyanna posted:I just take the mounds of process as a reason to try and be less pressured and hurried. If it's gonna take a while, I might as well let my blood pressure benefit from it. Yep. I don't think I'm going to stress out if something like that holds up my job either. Though I heard a few stories about managers breathing down on the development team's neck and demanding the thing for yesterday, when the thing is held by company
|
|
#
?
Mar 10, 2016 16:17
|
|
|
Vulture Culture posted:Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement? So, the last place I worked had an Agile coach come in and he flipped out about time tracking, even for measuring costs, which I think is too far. Personally, I think there is value in estimating story points as a measure of how complex you think something might be, and as a team, of course you're going to get estimates wrong, but if you are consistently wrong, you can still come up with a general idea of how much your team can accomplish when you start measuring velocity over several iterations. I think trying to estimate hours is a fools' errand and should be right out. Inevitably, some douchebag project manager will ask, "Why did this feature take a whole week when you estimated it would take 8 hours?" Because programming, bitch. Because QA, mother fucker. gently caress off and die However, I do understand the need to track hours spent after the fact, for purposes of capitalization. Some accounting wonk needs to be able to say, "we spent x dollars on build this project." So, I understand time tracking, but if management is using it for literally anything beyond that, I find another job. This is a job-seeker's market and I don't have time for your 60's era management bullshit. ChickenWing posted:Sometimes I think my job is a little goofy when it comes to their agile implementation, then I read this thread and feel better. Our agile isn't exactly making things better, but at least it's not actively making them worse. I don't think any Agile implementation is going to lack goofiness. If by some miracle a company has The Perfect Agile process, that in itself is goofy as gently caress and probably terrible in its own way.
|
|
#
?
Mar 10, 2016 18:29
|
|
|
Finster Dexter posted:I don't think any Agile implementation is going to lack goofiness. If by some miracle a company has The Perfect Agile process, that in itself is goofy as gently caress and probably terrible in its own way.
|
|
#
?
Mar 10, 2016 18:58
|
|
|
There is no perfect Agile process because everything changes to suit your needs and has to do so, also assuming that Agile is silly and ridiculous actually helps you work better in it IME.
|
|
#
?
Mar 10, 2016 23:20
|
|
|
Khisanth Magus posted:I hate places where you can't point out the person who actually broke something and tell them to fix their poo poo. At a minimum you should be able to talk directly to the person and tell them that they broke X and need to fix it. I pushed a change to our QA branch and the database access count went through the roof after a deploy. I said, "Hey X, I think the problem is related to this operation. Could you take a look?" to give him an out in the hopes that he'd recognize his mistake (a missing prefetch) and fix the problem. Instead, he replies all, "Hey, Jo, your code broke this and caused the storm. I fixed it." He removed a non-functional line that I had added and, in his commit, also subtly included a fix for his fuckup. I still get a bit flustered when I think about it.
|
|
#
?
Mar 11, 2016 07:31
|
|
|
Jo posted:I pushed a change to our QA branch and the database access count went through the roof after a deploy. I said, "Hey X, I think the problem is related to this operation. Could you take a look?" to give him an out in the hopes that he'd recognize his mistake (a missing prefetch) and fix the problem. Instead, he replies all, "Hey, Jo, your code broke this and caused the storm. I fixed it." He removed a non-functional line that I had added and, in his commit, also subtly included a fix for his fuckup. Wow, sounds like X is a dipshit.
|
|
#
?
Mar 11, 2016 08:57
|
|
|
Illegal Move posted:Wow, sounds like X is a dipshit. Yeah who names themselves after a letter anyway Where I work we have a couple different teams at different levels of the stack and the behavior of the teams is very... different. The middleware team is working a bunch with a sister company that mostly does web things to develop an electron.js app and they're all heavily (mostly because they have to be since the sister company is running most of the show due to politics) engaged in a big ol' agile process and it seems miserable! They also seem to constantly be in terrible drama filled trouble and have been through a couple complete leadership changes and I just don't get it. Meanwhile my firmware team is now 3 people including me for the next eight weeks or so due to a baby and while we have way too much work to do, at least nobody seems to argue with the old quick, cheap, or quality: pick two maxim.
|
|
#
?
Mar 11, 2016 14:19
|
|
|
Jo posted:a non-functional line that I had added
|
|
#
?
Mar 11, 2016 20:31
|
|
|
|
| # ? May 2, 2024 05:21 |
|
|
Vulture Culture posted:Our of sheer morbid curiosity, how do people in here feel about the #NoEstimates movement? On my previous team, we had a weekly estimating meeting on new stories in our pipeline. To do the actual estimating, we'd all read the card, then raise our hand (or otherwise indicate) when we'd made an internal estimate. We'd then go around in a circle and say our own estimates. I think the highest ended up being what we put on the card, but that never really mattered to us. It was more about seeing "are we all on the same page regarding the scope of this story?" If one person said 8 hours and another said 40, we'd go "whoa, why so high/low?" It often led to good conversations about what actually needed to get done with a little bit of how, and meant everyone knew something about each story, so they wouldn't go too far off the beaten path if they ended up pulling it. I liked it well enough, though I thought it was stupid to use hours and we should have done a sizing system (< day, 1-3 days, 1 week, longer, or something like that). In terms of actually using estimates for planning or communicating with management, I thought they were worthless, and I don't think we should have been sharing those estimates outside of that room, because they just lead to unrealistic expectations.
|
|
#
?
Mar 12, 2016 05:58
|
|
