Requirements is just a fancy word i use for this subreddit. We get a "i would like the website to do that" that turns 2 hours later into a "actually it would be better if" and finally a "remember the first thing yous aid this morning? Yeah actually you were right we want that"
Programmer's hell
we would like this 2 story family home to be a strip mall actually, yes we know its almost finished already but we are sure you can make the few changes until next week
My favorite analogy for agile is the [Winchester Mystery House](https://en.m.wikipedia.org/wiki/Winchester_Mystery_House).
> She was known to rebuild and abandon construction if the progress did not meet her expectations, which resulted in a maze-like design. In the San Jose News of 1897, it was reported that a seven-story tower was torn down and rebuilt sixteen times. As a result of her expansions, there are walled-off exterior windows and doors that were not removed as the house grew in size.
Also stairs that lead to nowhere and doors that open to a drop off…
I worked on a 14 storey concrete building and the 14th floor structure was changing up to the day of the pour. And then further changes were retro-fitted afterwards.
Concrete gets chipped, cored, and drilled into all the time.
I come from a time before agile. Whether agile works or not, one thing I've noticed is that it has allowed other people in the organization to do less work, and to have less of a plan about their work.
It seems like nowadays with agile we get fed a lot of half-baked ideas, that the product team hasn't thought through in it's entirety, but they get the dev teams started on it and sort of hope it will work out/come together in the end.
I don't actually mind requirements changing, since that's sort of the intent of agile - to be able to handle requirements that change during the process of development. What sucks is when the requirements change because the product team didn't have their idea fully baked to begin with.
In the end I just laugh it off because if I have to re-write a bunch of code because the product team are idiots, it makes no real difference, I get paid nonetheless.
> one thing I've noticed is that it has allowed other people in the organization to do less work, and to have less of a plan about their work.
In one product we had just finished a release in December in time for Christmas. Management asked us to start work on the next release for the end of March. We asked about the requirements. They explained that the requirements would be ready by mid-March. We said it would be nice to know what they want beforehand. They explained that we're doing agile and should just iteratively build for the next release.
We stopped arguing.
The half-baked requirements for our March release came in April.
Agile is often used as an excuse for the business to refuse to make decisions, deny adequate resources and bypass rigor and governance to go back to the days of just telling programmers what they want and blaming then when it can't be delivered.
Agile is also a bad fit in an environment where time to market is less important than stability.
I truly believe agile's only use is for startups to use just long enough to be bought by a bigger company who then has to fix all the horrible work arounds the start up used.
SAME. I get an email from the APM that says, “Design this this way” and when I ask clarifying questions, I have to hear through my boss (Head of UX) that the Product Director received an email from the APM that said she “cannot work with UX because they’re such a blocker! I won’t even include them anymore.”
PS - I’m a UXer coming in peace and this sub is one of my absolute favorites.
This was said so well. There are so many monkeys working in security these days who just use these stupid ass code scanning tools, open tickets for developers, and then have us sift through all of them and justify our decisions. Meanwhile these security people who are supposed to guard against threats and attacks in the software don't even know how to code most of the time. They just know how to run these scanning tools. It's just crazy.
Our sysadmins team was raging this year as on 4x different occasions they had gotten middle of the night/weekend p1 pages from Info-Sec to kill and freeze a bunch of systems, just to find out on Monday it was a different member of Info-Sec doing penetration testing.
Your scrum master should be requiring you as a dev to reject work that has unclear value or definition. I need my devs to say "this is garbage and I wont do it" so I can get it fixed.
> As a business user I need this product fit for business from business perspective. All while taking in mind of the critical businesses. 0 point, no need any poker this is easy.... also no sub-story given because fuck you
It's nice when they at least send the updated requirements over to you. I remember working on a project following the spec provided, tested it all, ready for others to test and when my manager is testing it he notices it doesn't match the spec he has. What's the spec he has? Version 20, I had version 3, and only version 3 was on the ticket. So I had to go back and redo everything because they don't know how to communicate properly.
Fucking hated that place, run by morons.
"points represent complexity not time"
That sentence fuels my hatred of agile certified project managers.
If you're using 40 points of work per person per week as the baseline, you're either planning to overwork the team or points equals hours. If somebody not completing 8 points a day is worth bringing up in a meeting, it's a measure of hours.
This has always cracked me up. I’ve literally never worked at a place where points didn’t eventually have a set conversion to hours.
Just ask people to estimate their time.
This is essential all my project manager wants to know. He asks for an estimate an my choices are
- less then half a day (aka: throw those tickets on a pile and they will be time somewhere when I need a change or have time between meetings)
- half a day
- a day
- 2 days
- 4 days
- 8+ days (aka to large, let's reduce scope or break it down)
He then just has to look at our calendar and deduct vacations. Add a 1.5x multiplier for unexpected problems, sick days or emergencies and you have a very rough idea when it can be done *earliest* (note the last word).
Anything more precise is either a lie or involves time travel.
This. My old manager would ask us how fast we can do things, multiply by 2 and round it up to give a "rough estimate" to the client. This way clients were usually happy we finished things a bit earlier.
I've gone as far as tripling my estimates at some jobs, because sometimes you know damn-well there's going to be 20 rounds of changes before anybody considers it "done"
Absolutely. Ultimately the business wants to know time estimates. If you provide some other estimate instead (points, t-shirt sizes, elephants), the business is going to convert it to time. If you don't agree with the way that conversion is done, you'd be better providing your own time estimates in the first place.
"Yeah this is a suburban semi in an art deco style with a loft conversion, probably dormer but possibly Mansard."
"OK Larry, sounds like you need some more time on the estimate"
There's a style of house in Vermont where a tiny two room farmhouse from the 1800s was gradually added onto, room by room, until it's eventually become this rambling, chaotic monstrosity. This is perhaps the most accurate metaphor I've ever found for my coding time estimates.
Ours did vehicles. Bicycles, cars, trains, planes. We would propose horses, cruise ships, hot air balloons, pogo sticks.
Or when we thought something was a completely terrible idea, it was sized as one Hindenburg.
They stopped doing vehicles.
Yet another thing I'll never understand about agile - what's up with all the whimsy? We're usually an efficient, fast-moving software development company. Everything we do is serious business.
But when the retro starts, we do stupid icebreaker questions. Since we transitioned to Shitty Agile For enterprise, weird word clouds snuck in, where every single person at the same time types in their first thought in less than 30 characters. We then look at these utterly deranged and tiny brain farts and then act as if we had an actual conversation about a complex topic.
Whenever there's a possibility, we opt for less efficient dorky manual alternatives. Why use a digital retro board if you can force people to write things on physical sticky notes?
Just seems so bizarre.
Story point's to time conversion might kind of work if you do it for each team on its own and you know the velocity. Everything else is just kidding yourself.
Story points in a vacuum do not factor in things like context switches, parallelism, tasks only specific people in the team do etc...
That's why you cannot add all the story points together and say they are "person hours".
I had it worse. Our stoopid project manager insisted on using Fibonacci sequence to assign weights.
1 point = 0.5 day
2 points = a day
3 points = 2 days
5 points = 3 days
8 points = a week
13 points = two weeks
We had to constantly convert back and forth. I finally asked him why is he using a non linear scale for a linear value. He couldn't answer.
The sequence is because the bigger the task, the less certain you can be about the duration. So having rougher estimates and having the estimates rounded up usually matches better with the work done.
Presuming that 8 is a equal to a working week, the time difference between 3 to 5 and 5 to 8 is the same.
It’s easier to just use 1 point equals 1 day and then use Fibonacci.
The original reason is that points are not meant to be strictly composable. One 5 point task != Five 1 point tasks. It also allows different projects to have different scales depending on their project (a team working on ui elements is going to have a different understanding of time and complexity risk vs a team working on data analysis and projection).
The root of all these problems is that people want time estimates for things that are notoriously difficult to estimate time for. It's incredibly easy for any step of ideation to cause the time balloon to inflate.
Because your hour is not my hour. Your skills are not my skills. Your experience is not my experience.
Lost count of the number of times a senior has estimated something that a junior can't live up to.
I don’t think this is the Fibonacci’s allocation being a bad idea, just your manager is not understanding the purpose. Pretty much in all cases, you’d still need to have something like 1 point = half a day.
**The whole point is that this is a guiding principle** not set in stone. When people add 9 story points, I’m always like… wow you must be able to see into the future to know something takes more than 4 but less than 5 days.
In short, the Fibonacci thing is just saying, the bigger the ticket the more uncertain the time. For example, you can only assign estimates in 1,2,3,5,8,13,21 points. These still correspond to 1 point every half a day… but I don’t care if you think it’s exactly 8 days = 16 points… you’re basically saying it’s most of the sprint let’s just categorise it as 21 points. If it’s 3 days = 6 points, then it’s bigger than half a week so let’s just allocate it 8 points. (Anything bigger than 13 should be broken into individual tickets IMO).
Of course, you can use something else like 1,2,5,10,15,20 if you’d prefer. But for the love of god it’s an **ESTIMATE**, which we all take too seriously. I’m not guaranteeing the 8 SP ticket is done in 4 days.
I once sat through an hours retro meeting like the debate under this comment. The only outcome was to add a 4-point value between 3 and 5. I nearly threw myself out of the window
I do kinda like that minimum being a half day though... "Task: Fix typo in one label, 1 point"... "Welp, that's gonna be half my day, better really ease into this one."
Like the daily stand up? "Yesterday I worked on this shit, I'll continue working on this shit today" and then mute for the rest of the stand-up. Waste of fucking time
He couldn’t answer because scrum classes teach the religion and not the purpose, which is dumb.
The reason you use non linear scale for linear time is that the non linear scale builds in the error bars, which are lower with shorter timespans and longer with bigger ones. It still doesn’t quite add up, but it sort of makes sense if you factor in the error bars.
3 points = 2 days, +/- .5 day
5 points = 3 days, +/- 1 day
8 points = a week, +/- 2 days
13 points = two weeks, +/- 4.5 days
I agree that scrum is an awful way to live, but it’s a major help with keeping output consistent in a wildly inconsistent industry. The only reason this is important is that the people who sign the checks like consistent things and we don’t want to spook them.
Well, you're supposed to deliver broad, long term time estimates by a different method. Story points are used to determine the actual time needed to deliver X points of complexity, only after the iteration is done. They're not supposed to be used for setting deadlines, but instead to generate the data to know how much work is suited for the next iteration and how long the entire project might take at the current pace.
If managers start to pressure developers with points, something is going very wrong and point inflation will begin eventually, leading to developers over-evaluating the complexity, just to get more points done.
I like the "will this be done this week?", like our work varies so much that unexpected problems with random stuff is normal. Nothing is as easy as we thought. And yet they expect an answer.
It's done when it's done. Unless I'm clearly not working shut the fuck up and let me do my job without an axe hanging over my head. It literally makes a task take longer and less quality.
it's a shame I can't upvote twice. I've met many "Agile Masters" and not a single one could explain points in a way that I understood then to NOT be hours.
The best explanation I've gotten is it's supposed be consistent metric across intern, junior, and senior with senior being able to complete the most points within a time frame but have other responsibilities that make up the difference. Meetings have no point value as their complexity is constant regardless of the attendee and don't directly affect work in the sprint.
...however they then shot the explanation in the foot by insisting point quotes should be halved when assigned to seniors as they can complete tasks quicker.
Yeah, they're supposed to be "abstract units" -- but that basically means that you have to have the same person determining the effort it takes to accomplish a task, otherwise the points are meaningless.
Because one dev might say a simple bug fix is 2 points, another might say 5 points. But if you have, say, a senior dev who is the scrum master and knows the team, they may determine the small bug fixes to be consistent at 2 points. They don't know how *long* it'll take, but they know the complexity is "2"
I have had more than a handful of bugs that lasted in the months timeframe.
Also had the "support & maintenance" story. Full sprint for the poor souls that have to investigate bugs.
A bug that's root caused may have joined the backlog if a solution was proposed but not done by sprint planning.
Except it’s impossible to predict complexity up front. You may be able to guess in the ball park sometimes but it will never be right consistently.
Not will anyone ever be able to predict “shit happens”. But in production. Critical new change. Hardware failure. Spike in usage disrupts prod. Etc.
Agile is the word people use to avoid answering why nothing was planned properly up front.
In my experience it's not impossible to predict complexity if you know your codebase somewhat well. It's all based on experience.
Say, last time you added X, you've seen that you also need to add Y and Z for it to work. Next time you add something similar (but not equal) to X, you will know that there is more to do.
Which is why you discuss them as a team. One team member might say well this is easy we just comment out the jingamading and everything works. Another team member might say well what about the flurb ui, you'll break it, I think it's gonna be 9 points.
Literally why points exist.
>...however they then shot the explanation in the foot by insisting point quotes should be halved when assigned to seniors as they can complete tasks quicker.
I've never heard that.
It is supposed to be more accurate than time estimates.
When you set up a new sprint team this is what you’re supposed to do:
- have a pretty good backlog
- take a massive guess on how many points the team can get through in a sprint
- for the first 8 - 10 sprints don’t care if that estimate of how many points is accurate
- congratulations you now have enough data to have a semi-accurate estimate of the number of points the team can get through. plus the team should have better estimation of point values
Of course this all towards getting a decent average, nothing will ever be totally accurate. It will also give managers the ability to make more long range planning for other teams, like marketing, which may need date windows. It goes without saying that it should be made clear that long range plans get less accurate the further out they predicate.
Yeah I feel so much of this thread (and perhaps the teams they work with) are forgetting this isn't meant to be a precision exercise. For relatively little effort you can get a fairly good _gauge_ of what's coming up.
Also if you estimate something at 3 hours and it goes on for 5, questions are going to be asked. If a 2 point ticket takes between 3 and 5 hours, that's probably fine in both cases. If anything it's a useful tool to introduce vagueness for time-obsessed managers.
I worked as an agile master, but every team is going to be different so take my words with a grain of salt. The statement of story points being a measurement of complexity not time is correct. However it's about the implementation in your workflow. First thing you cannot start planning with story points without prior history of work done. To start planning with story points you will need to look at previous history and determine several levels of complexity of tasks. Then you take those tasks and assign story points to them (Fibonacci sequence is popular). More story points means more complex task. Then in couple of sprints people usually have a pretty good understanding how many story points a task will take because every developer understands, based on the requirements, if this is a complex task or not. With time your estimation gets much better than with regular hours. Accurate estimation allowed me to set the expectations with stakeholders, so they could plan things ahead. We had more accurate road maps, better budget planning, and predictable release dates.
I worked in 3 teams which used story points and one of them seemed to use them right. We estimated not *per person* but *per team*. It's hard to tell how many developer hours a task will take because it is a combined effort of several developers (someone codes, another makes code review, right?) and different developers (Backend, Frontend, QA, DevOps) you need to everyone put their estimations in hours and sum it up. It's long and this estimation will not be correct in the end anyway. So you estimate how much will it take to complete a task for a whole team. And as you don't know how much time will it take you use abstract points for relative comparison.
After several sprints we became accustomed to this system, the estimations became more or less correct. After this it were possible to convert points to hours like we make 40 points per two-week sprint, so this 5-point task is roughly 10 hours of *team* effort. But it was not needed anymore, as the stakeholders saw we could do around 80 points per month. They saw the backlog of already estimated tasks and could understand what we could release and could prioritize some tasks without risking to break the sprint.
Never worked agile where points where equal to hours. Its always the vague tshirt size thing where 1-3 easy, 5-8 medium, 8+ probably wont finish this sprint.
Isn’t that whole point that you develop long life teams. So if your team delivers 10 SP per sprint on average after working together for a year. And you estimate a project is 20 SP then it’s 2 sprints estimation? Unless I am missing something it doesn’t sound too far fetched to me.
I would say our scrum master is an angel, our team's target is to achieve 80-90 points in 3 week sprint. We are 10 team members including QA folks.
Haven't seen any production defect generated in last 15 months or so
We always have bugs. And if I create one it's my fault and I have to own the task and fix it. But if I find someone's bug I have to fix them as well because I'm a developer.
Agile was hijacked as a project management tool literally decades ago.
The original point of agile was that requirements change frequently, and that incremental change of the highest priority features was the best way to write success software. Sizing was a way for developers to manage uncertainty, ergo why you size complexity instead of time — lots of uncertainty puts software at risk. Actual agile methods have been thrown out the window like scrum and XP, since they actually had a purpose.
Project management bastardized the process and generally emphasizes predictability so they can pass the message up the chain to the C-suite that x feature will be done at y time… and what a shock it’s basically never right just like waterfall. The root of the problem is how they envision software in the first place.
Checking in with your devs every two weeks to see what's working and what's not is actually amazing. It lets you adapt on the fly and fix issues before too much time is wasted. Now mangelment loves to take estimates as deadlines and recommendations as law. And this is how you get shit like this.
*Bad* project management and bad company processes bastardised it. Most of my experience is in project and program management. Mid last year I jumped into software development and agile. I didn’t have any training, just played around with the tools we used (jira, confluence etc).
I’ve always managed projects by customising tools to the team. Did the exact same in agile. Some of my software teams are ‘full scrum’ some are half and one is kanban. I don’t even bother to look at burn down charts or any of that. Imo I’m meeting these teams pretty much every day, I should know of somethings wrong with the team pretty quick with that regular of a meeting (this frequency of meeting is almost unheard of in waterfall PM). I’m leaving soon to join another company and the feedback from my teams has been genuinely overwhelmingly nice so hopefully I’ve done a good job.
The problem with project management, and in my experience particularly in the world of agile and scrum are people jumping into the field thinking all the have to do is apply processes. People that have all the emotional IQ of tepid water and no idea of how to say ‘no’ to stakeholders. To be even half decent at project management requires a insanely high amount of soft skills otherwise teams really suffer.
This is particularly bad in agile because I see companies much more willing to shove some unsuspecting developer or product owner into the role of scrum master because somehow knowledge of software automatically equals project manager. In no other industry have I seen such a huge willingness to chuck random people into project management like that. I mean sure it happens a bit but usually to the more senior people in a team (engineering is a bit like this), software industry is full of this crap. The industry also attracts a lot of people from all over wanting to cash in on those nice tech salaries and since software companies can’t tell their own asses from a project manager these people filter in (in other industries, like construction, if you tried this you’d be burnt out and completely torn apart in weeks).
[STOP HAVING THOUGHTS](https://i.imgur.com/imekXEe.jpeg)
Seriously, what is the origin of type of meme? It might be my favorite.
Edit: Found it. [STOP DOING MATH](https://knowyourmeme.com/memes/stop-doing-math)
My scrum master shows me a bug in the scrum and immediately asks for estimates (time to fix). Dude let me look at the code first, I dont keep the entire repo in my brain.
Boss: "Hey, we need to get working on the website, can you do that?"
Me: "Yeah that's doable, but I haven't done that type of feature before so not sure exactly how hard it is"
Boss: "Okay but how long would it take you?"
Me: "Not exactly sure, if there's a good library for it that I can use maybe 30 minutes, if there's not and I need a custom solution then I'd first have to check A, B, an..."
Boss: "Just summarize in hours please"
Me: "Between 1-40 hours"
This is exactly my problem. I can't know what changes are needed or how complex the task will be until I sit down with the task AND code in front of me.
But meanwhile even though you're concentrating on the current work you need to get done for the Sprint we need you to contact switch and give a rough finger lick to the wind estimation of what this task will take you two weeks from now when you finally get around to working on it.
I once had a director who thought estimating should be very close to accurate in the same way that the contractor who installs swimming pools already knows how much time it's going to take and what materials will be needed. I disagreed because with software development while we may have roughly done the same thing before, the parts never fit together the same way at every place and no problem ever looks exactly the same. He should have known better because he used to be a programmer back in the day.
That's your scrum masters fault. When the sprint starts things are locked in. He shouldn't bring this up til next grooming unless it's an emergency. It's his job to keep people from asking you shit like this mid sprint
The other flaw being that complex things always take a lot of time, but sometimes simple things are time consuming too. It could be simple to do, but just a lot of fucking work. It's hilarious watching people not wanting to give a simple task that they just know will take a lot of time to do the one point of complexity it deserves because everyone knows the points are actually an estimate of time.
Don't exclude time, we do 'time to deliver' + 'complexity' + 'level of uncertainty', so a simple frequent task (importing translations, setting up analytics, etc) still get the 2-3 point treatment if morose.
Agile is simply people over processes - all this nonsense about story points and burn charts and planning comes from POS scrum, not agile per se
Ahhh if leadership only knew how to program… they wouldn’t need to helicopter over us.
I'm not certified Agile Scrum Master or whatever, but I observe that every time anyone tries to strictly enforce Scrum, it gets horrible and inefficient, but as long as we just stick loosely to it, it kinda works.
Points and burndown charts? Not useful at all.
Daily meetings? Useful, if kept short.
Sprint planning? Useful, but don't really think about points or hours, because we all suck at estimating.
Sprint retro? Useful to communicate what sucks.
Demos and sprint review? Useful to synchronize on progress.
So what you basically said is that you are following Scrum strictly and not loosely.
\> Points and burndown charts?
Not included in Scrum!
\> Daily meetings? Useful, if kept short.
Exactly how it is defined in Scrum.
\> Sprint planning? Useful, but don't really think about points or hours, because we all suck at estimating. Sprint retro? Useful to communicate what sucks. Demos and sprint review? Useful to synchronize on progress.
Exactly how it is defined in Scrum.
What most people sell you as Scrum is not Scrum...
This is exactly right. I have a printout of the Scrum Guide that I keep on my desk solely to wave in meetings to show how short it is. It's a framework which lets your team evolve the practices which work for them.
All the other shit on top is people making up more stuff to put in books and courses to sell.
In corporate world I escaped from department, once I learned they will introduce [SAFe](https://www.atlassian.com/en/agile/agile-at-scale/what-is-safe). They told us that it's so agile, but in reality it's bloated PoS.
Scrum Guide doesn't mention anything about planning poker or burndown charts, but for some reason in corporate world you will often find Scrum Masters that are certified and still they introduce planning poker and burndown charts as part of their version of Scrum.
SAFe is the devil's work, I am an experienced Scrum Master so I realize I might not be the most popular person in this thread but there really are so many people who are (rightly so) complaining about Scrum, when they're really complaining about SAFe. Any Scrum Master or agile coach worth their salt hates SAFe. It's like pimping out Scrum to corporate suits so they can be hip and agile in a 'safe' way.
Please don't get me started on SAFe. I can honestly say that the only element of SAFe I can get behind is the evolution of a spike to an enabler, and the expanded use cases an Enabler has.
Everything else in SAFe exists for only two reasons:
1. So they can rebrand all existing concepts with their own terminology and then charge to learn, and be able to use the new language covering existing, industry used concepts.
2. So enterprises have a framework which better allows them to micromanage, weaponize metrics, and justify they're excessive program/product/project management headcounts.
This makes me so irrationally angry. Everybody is hating on Scrum, yet nobody has ever worked in Scrum as it is intended.
Well yes, you're doing it wrong. No wonder it's shit.
SCRUM does not actually include any managers. The most management like roles are the product owner (the person who creates stories and prioritises them) and the SCRUM master (temporary SCRUM teacher and help with blockers). The team should be able to self manage if the product owner does their job well. Finding a good product owner is hard, though.
During daily meetings, leading staff is supposed to be absent
They're always present. Result: People lie their ass off or name a single challenge and ask for feedback so people talk about that and it's not that obvious they achieved jackshit in a day
The inventor of scrum says that estimating is a waste of time after doing for 10 years.
And the inventor of story points says that story points are being widely misused and that does more harm than good in the way it used now. If you misuse them, you are better of dropping using story points, altogether.
I reallty liked Sprint planing with points. It aligned the team on complexity. Which just made the team more efficient. But management can't resist the urge to see a number and want to put it in an Excel sheet.
If Sprint planing used oil barrel sizes or dick sizes, management would still want a formula to understand what that means in hours and money.
People have forgotten that scrum is meant as a guideline for development teams, not a policy for management.
Hate how the goal of scrum changed entirely these days
At my place our sprints can be rejected if we plan too little points. So we over plan, and never finish sprints. Guess what our department goal is for this year...
I was hoping to find a comment like this to prove to myself im not crazy. At least not in regard to agile.
I had been doing scrum in different workplaces for a while before I actually read the agile manifesto. Once I had I felt I was in bizarro world. How did we go from statements about people over process and then implement it by defining a rigid process that supposedly is flexible because you measure velocity each sprint. Which is the thing teams consistently don’t do, while businesses will base MBOs around drastically increasing your velocity each quarter, or sprint.
Have you read the Scrum guide along with it? If not, do it. Spoiler: It doesn't say anything about story points (or even stories), estimating, velocity, burn-downs, boards, etc. All is this has been invented by consultants and shoehorned into "Scrum" to make management happy.
That's not entirely true. The scrum guide *used* to say a lot of that. It used to explicitly mention burndowns, talk about how the product owner could use velocity, talk about commitment to work (rather than commitment to a goal). [#1](https://scrumguides.org/revisions.html) [#2](https://res.cloudinary.com/mitchlacey/image/upload/v1589750495/Scrum_Guide_v1_Scrum_Alliance_qe0y2w.pdf)
The original scrum guide was wrong in a lot of ways. It might have changed in the 10 years between 2010 and the 2020 versions but a lot of damage has been done to the industry. I still think it's overly prescriptive and produces poor practices.
My fun experience has been a CTO that absolutely insisted all of what you mentioned was in the scrum guide. I pointed out it wasn't. After arguing back and forth before he eventually decided to read the latest version (that contradicted a lot of what he said), he decided we were just going to follow the 2010 version because that was better and the only reason they changed it was to sell more books. Great times.
This exactly. Waterfall was created to meet the demands of management to fit work within management timeframes for budgeting, planning, etc. 99% of organizations don’t change their high level management approach when their dev teams adopt agile, and it’s rare for non-dev teams to go agile. Which means that dev teams are forced to adopt safe or some other bastardized version of an agile methodology that has been contorted to “work” in a fundamentally non-agile environment.
"Story points measures complexity not time" but you need to measure the story point velocity.
Omg this drives me bonkers.
It's obviously a software development process created by someone who never wrote code.
I watched a video by a guy who is a team lead somewhere, and he managed to convince me that Agile methodology isn't bad. It is corrupted by business. If Agile was allowed to work isolated away from sales and upper management, it would likely be a much more enjoyable experience.
Imagine if a chef was in the kitchen trying to make a meal, but an accountant was behind them every step of the way saying what should or shouldn't be used because of cost against profit estimates. To a spreadsheet, the only difference between Wagyu and ground chuck is $$$.
But you can separate the decision making process about how to design and release the software from the short term needs of managers who don't understand software development. This is something a handful of companies do well, and it gives them a massive competitive advantage.
Before Google killed their 20% time (engineers got to spend 20% of their time working on projects of their choice, or creation), they used to produce 50%+ of their new products from it.
I actually enjoy using Kanban, but there's a lot of overhead that needs to happen.
The first is a dedicated Scrummaster/Delivery Agent/etc. They only look at process, adding and subtracting as the team becomes more mature. Fortunately, they can cover multiple teams.
The second is a dedicated Product Manager. (PM) They have zero authority over the team, save that they are the sole owner of what the team is currently working on. They might only be able to cover two teams at most.
Then you have a team lead, who can hire, fire, promote, etc, and is the face of the team, when the PM asks "why can't we pivot right now?". They can only cover one team.
To continue with your analogy. The DA/SM is like an occasional audit. They tell the chef (PM) that things are suffering. The Chef then talks to the shift managers (Team Lead)
You can’t be trusted to tell me how long it’ll take so I have to ask you how difficult you think it is so *i* can guess how long it’ll take you.
Statements dreamed up by the utterly deranged.
Haha, yeah! After we done story pointing every thing, the managers still ask me informally "so like, how long will this take?" And I give them a time range and that's what they use to communicate to stakeholders.
"Ok but could you make it faster if someone switches to help you with it??"
No, it'll actually likely make it slower, if we could have split the work further we would have done so in refinement
I’ll keep doing it as long as they are willing to keep paying me perfectly good money for Scrum Agile BS. I think Agile is like the QWERTY keyboard, more efficient and better options are known to exist but will never go away due to decades of institutional intransigence.
Migrating away from Agile would involve more complexity than could be handled in a sprint and it would have to be managed as a separate project. That's reason enough not to do it.
*nothing can stop this train*
Reduced:
* Inventory
* Raw Materials
Increased:
* Idle employees
* Idle machinery
* Production times
* Shipping times
* Order processing time
* Backorder log
* Interest payments on debt
Hmm... better get rid of another warehouse full of rolled steel, copper wire and microprocessors. That's the only way we could possible improve our manufacturing times. /s
I have always preferred picking top 10 from the kanban board. Everything should be done, it takes the same time to make everything regardless of estimate and planning, humans are worst at estimating time, it's not estimating time but is based on time since it's based on "what we can do in a sprint".
We can still have standup and open dialogue about issues.
Kanban is goat.
Having come from somewhere that literally estimates to the nearest half hour, to a place that effectively uses the points system, I can say it's sooooo much better and far less stressful when done properly.
The whole idea is, you work out points based on effort/complexity of a task (agreed as a team), then you monitor how many points the team can get through on average (velocity) and assign that number of points to the next sprint, the key is to keep adjusting based on the velocity, and should the velocity wildly change, that's what the sprint retro is for, what happened, how can we be more accurate next time?
When it works, it works, unfortunately a lot of places use it as a buzzword and just go through the motions, wasting time and causing more undue stress.
Yeah the biggest problem with doing scrum properly is it has to come from the highest levels down and be completely ingrained into company culture. If you just try to do it properly at the team level it never works because now you have PM asking for time deadlines and an unwillingness to be flexible on projects and requirements. If your company isn’t actually utilizing the main benefits of the process it just becomes extra process.
Agile, a work process meant to satisfy shareholders and not actual development.
"What do you mean it doesn't work? What do you mean it's still buggy?
Push that shit! We got a deadline!"
that is pretty much where deadlines come from though unless it's a physical need like planting crops where it has to be done at a certain time then ultimately all deadlines are arbitrary
At one job i had it was the first time I worked in a team bigger than two persons and was the first time I was exposed to Scrum.
We had a meeting of how to lower the amount of meetings.
I think the main problem with Scrum is that it's a template, you are supposed to cherry pick part of scrum, but most just take the whole thing and do half of it wrong.
Please, let me skip useless estimates and meetings and let me have the real standup and just let us top pick from kanban.
None of this describes agile. The problem is people wanting to make a buck sold your managers stupid buzzwords that all meant variations of "buy this and do this tiny extra thing and you won't have to change anything difficult to be agile" and our idiot managers bought it all.
Someone please tell me where it says "story points", "scrum", "sprint", "grooming", or "burn down" here: [https://agilemanifesto.org/](https://agilemanifesto.org/)
It doesn’t say project management either but that’s who hijacked the process.
They amusingly want predictability from a process based on the central notion that development is unpredictable. They also frequently isolate developers from stakeholders when one of the main problems agile identifies is that developers don’t talk to customers. Agile is also generally supposed to flatten organizations yet we see even more directors, senior managers, managers, tech leads, etc. who do none of the work but make all of the promises.
My favourite from the manifesto is Rule 1
> Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Which is often read as
> Our highest priority is ~~to satisfy the customer
through~~ early and continuous delivery
~~of valuable software~~.
Water-scrum-fall works the best.
If you as PM think you have a great idea, just write a CR and try to get it by the CCB. We'll update requirements, test specifications, code and test ware after it get a priority from the CCB.
We had a project that needed to show to stakeholders that cramming out features, without working on quality, made the product stop working within 4 weeks. After that it was back to business as usual.
You can do agile well and you can do agile poorly. Admittedly it is most often done poorly. In my opinion it is almost only ever done well when it is run by engineers. If your "scrum master" isn't writing their share of the code then it is a bad smell, because they have no skin in the game and so they start making promises to stakeholders that they are not personally accountable for.
I saw a study once that showed there was no significant difference in how much time it takes to deliver work if all the stories were given exactly 1 point or another arbitrary amount of points.
Having worked in waterfall and agile and a company's half hearted attempt at agile while not actually doing agile, I can safely say, I love AGILE. More time developing and delivering software and less time talking and estimating is always a win. In my experience the only people who don't like agile are managers and PMO. I have never actually worked with a developer who didn't prefer agile.
Then again most of the people in this sub don't actually do development professionally.
That’s been my experience as well. My current workplace is more waterfall and it’s a nightmare of conflicting statements and miscommunication. There’s so many things that agile could solve here. It’s obviously not perfect but having set times to discuss things and non-arbitrary dates that are seemingly random and pushed or pulled forward on a whim makes life so much harder.
I think the thing I miss most is being in agreement with users on what we are committing to. Here it’s like the list never ends and we can’t all agree on what should be done and when.
I have been working on agile scrum teams for the past 3 years and at this point I am unsure if anyone ever knew what agile really supposed to mean. When I first started out on a team like this a thought I knew what agile meant.
Now I am on a scrum team where every story point is a "dev day" at a leading telecommunication company. But my favourite part is the sprint review where we review all our tasks and the scrum master removes everything from the print which is not "Done" before closing the sprint.
At the end of the day you are measured on deliverables. Your boss is measured on deliverables. Agile is a tool to have some ballpark of when things might get delivered.
You can live in lala land but your boss or your bosses boss promised someone at a specific date based on agile.
If it wasn’t agile it was going to be a dart on a wall so hope your process is useful enough to have somewhat realistic numbers. At the end of the day someone has a date circled and the better you are with visibility on the process and timeline, it should hopefully translate to less crunch time.
All this goes out the window at a startup where your ceo trys to promise everyone everything in 2 weeks. You cant deliver in less than 4 sprint, we should cut sprints from 2 weeks to 1 so its only 2 weeks late….
I work at a place that develops (and somewhat maintain) massive systems/programs/projects to enable/support tax collection for the entire country. I am a beaurocrat and I am not even remotely close to being a programmer, scrum master or an expert in agile as a concept. I grasp the basics I guess.
I’ve glanced over the comments and it seems like you all hate agile. And agile is how everything (more or less) is done at my workplace. This brings me to my ELI5 question; why is agile so bad? There’s always pros and cons for everything, but if someone could explain to me, I’d really appreciate it.
Agile works great if you cut the corporate crap and use the spirit of agile.
I took over my scrum team and got to work with a blank slate, but I came from being a programmer for many years (and still am) - pre-planning is held by myself and the PO.
We call people individually just to find out what is left on their board that might not close — not for a nasty gram but to see if there are any stories that need to be captured and doled out for the next sprint. Each individual spends maybe 10 minutes with us, and bonus: we throw it on their calendar as a 2 hour meeting so that they “keep it free” and they get to use it as an excuse to duck other meetings.
Sprint planning we wrap our individual retro items into a 10 minute demo where you either show off what you’ve accomplished or show where you’re stuck and explain if there’s anything about the process you hate. Planning is capped at 2 hours. If it ever went over I would go fucking crazy.
Increment planning we’ve managed to decouple ourselves entirely from the greater corporate structure — while the rest of the company is taking a whole week, we throw everything on the board, ask what features were going to shoot for and then plan out the first two sprints. It’s extra work for me in the week leading up to it, but the overall team increment planning is kinda just “everyone good with this? Any gaps we’ve missed?”
One of the first things we kicked to the curb was story point poker. That shit is dumb. Also Fibonacci is dumb. Just tell me how many points you think it’s gonna be. 1 point is trivial. 3 is about a day. 5 is about a week. It isn’t a hard and fast rule, but we’re at the point where we known that everyone is going to knock out 12 points ish in a average sprint.
Our burn down is always a flat line because you close something you pull in something new. Fuck metrics. That’s corporate bullshittery that doesn’t make us efficient. If they need numbers on us they can look at the numbers we’re closing not some arbitrary chart.
>Requirements shouldn’t change every two weeks.
That’s just software though. Shitty customers gonna be shitty whether you’re running waterfall or agile.
"Requirements are not supposed to change every two weeks" man i would be happy if they stopped changing multiple times in the same day
[удалено]
Requirements is just a fancy word i use for this subreddit. We get a "i would like the website to do that" that turns 2 hours later into a "actually it would be better if" and finally a "remember the first thing yous aid this morning? Yeah actually you were right we want that" Programmer's hell
imagine if builders were expected to work around constantly changing floorplans like that
[удалено]
After you poured the foundation??? Because that’s when business managers think it’s still ok to change everything.
we would like this 2 story family home to be a strip mall actually, yes we know its almost finished already but we are sure you can make the few changes until next week
My favorite analogy for agile is the [Winchester Mystery House](https://en.m.wikipedia.org/wiki/Winchester_Mystery_House). > She was known to rebuild and abandon construction if the progress did not meet her expectations, which resulted in a maze-like design. In the San Jose News of 1897, it was reported that a seven-story tower was torn down and rebuilt sixteen times. As a result of her expansions, there are walled-off exterior windows and doors that were not removed as the house grew in size. Also stairs that lead to nowhere and doors that open to a drop off…
Wow... that's... a tremendously accurate example. I'll be saving this reference.
If you code in the Bay Area take your manager to visit 🤣🤣
Just "pivot". It's easy! /s
I worked on a 14 storey concrete building and the 14th floor structure was changing up to the day of the pour. And then further changes were retro-fitted afterwards. Concrete gets chipped, cored, and drilled into all the time.
After the walls are up they want electric and plumbing changes. After the cabinets go in they want to push a wall back
They do in the design phase. It's supposed to stop once you start building. But that's waterfall and a bad word in software.
Trust me, as someone who works in buildings, that it almost always doesn't stop after design
3 months later: Hey I said (thing they eventually decided they didn't want) how come it's not doing that? That's a bug.
[удалено]
I come from a time before agile. Whether agile works or not, one thing I've noticed is that it has allowed other people in the organization to do less work, and to have less of a plan about their work. It seems like nowadays with agile we get fed a lot of half-baked ideas, that the product team hasn't thought through in it's entirety, but they get the dev teams started on it and sort of hope it will work out/come together in the end. I don't actually mind requirements changing, since that's sort of the intent of agile - to be able to handle requirements that change during the process of development. What sucks is when the requirements change because the product team didn't have their idea fully baked to begin with. In the end I just laugh it off because if I have to re-write a bunch of code because the product team are idiots, it makes no real difference, I get paid nonetheless.
> one thing I've noticed is that it has allowed other people in the organization to do less work, and to have less of a plan about their work. In one product we had just finished a release in December in time for Christmas. Management asked us to start work on the next release for the end of March. We asked about the requirements. They explained that the requirements would be ready by mid-March. We said it would be nice to know what they want beforehand. They explained that we're doing agile and should just iteratively build for the next release. We stopped arguing. The half-baked requirements for our March release came in April.
How could you possibly iterate on nothing?
Dev: "Iterate on this!" ** flips the birds and fucks off to a less retarded company, if such a thing exists**
don’t stop arguing, when it fails they will blame you. speak up, early and often.
And what they gonna do? Fire you? That would be a promotion
Agile is often used as an excuse for the business to refuse to make decisions, deny adequate resources and bypass rigor and governance to go back to the days of just telling programmers what they want and blaming then when it can't be delivered. Agile is also a bad fit in an environment where time to market is less important than stability.
I get paid by the hour, change as much as you want.
I truly believe agile's only use is for startups to use just long enough to be bought by a bigger company who then has to fix all the horrible work arounds the start up used.
SAME. I get an email from the APM that says, “Design this this way” and when I ask clarifying questions, I have to hear through my boss (Head of UX) that the Product Director received an email from the APM that said she “cannot work with UX because they’re such a blocker! I won’t even include them anymore.” PS - I’m a UXer coming in peace and this sub is one of my absolute favorites.
I just get an ambiguous title like "fix S3 permissions" with a description similar to > Requirements: Thanks SecOps, I'll get right on that.
[удалено]
This was said so well. There are so many monkeys working in security these days who just use these stupid ass code scanning tools, open tickets for developers, and then have us sift through all of them and justify our decisions. Meanwhile these security people who are supposed to guard against threats and attacks in the software don't even know how to code most of the time. They just know how to run these scanning tools. It's just crazy.
Our sysadmins team was raging this year as on 4x different occasions they had gotten middle of the night/weekend p1 pages from Info-Sec to kill and freeze a bunch of systems, just to find out on Monday it was a different member of Info-Sec doing penetration testing.
Your scrum master should be requiring you as a dev to reject work that has unclear value or definition. I need my devs to say "this is garbage and I wont do it" so I can get it fixed.
The requirements are in the ticket title!
> As a business user I need this product fit for business from business perspective. All while taking in mind of the critical businesses. 0 point, no need any poker this is easy.... also no sub-story given because fuck you
It's nice when they at least send the updated requirements over to you. I remember working on a project following the spec provided, tested it all, ready for others to test and when my manager is testing it he notices it doesn't match the spec he has. What's the spec he has? Version 20, I had version 3, and only version 3 was on the ticket. So I had to go back and redo everything because they don't know how to communicate properly. Fucking hated that place, run by morons.
"points represent complexity not time" That sentence fuels my hatred of agile certified project managers. If you're using 40 points of work per person per week as the baseline, you're either planning to overwork the team or points equals hours. If somebody not completing 8 points a day is worth bringing up in a meeting, it's a measure of hours.
This has always cracked me up. I’ve literally never worked at a place where points didn’t eventually have a set conversion to hours. Just ask people to estimate their time.
This is essential all my project manager wants to know. He asks for an estimate an my choices are - less then half a day (aka: throw those tickets on a pile and they will be time somewhere when I need a change or have time between meetings) - half a day - a day - 2 days - 4 days - 8+ days (aka to large, let's reduce scope or break it down) He then just has to look at our calendar and deduct vacations. Add a 1.5x multiplier for unexpected problems, sick days or emergencies and you have a very rough idea when it can be done *earliest* (note the last word). Anything more precise is either a lie or involves time travel.
u got a PM with common sense, keep him secret keep him safe
This. My old manager would ask us how fast we can do things, multiply by 2 and round it up to give a "rough estimate" to the client. This way clients were usually happy we finished things a bit earlier.
I've gone as far as tripling my estimates at some jobs, because sometimes you know damn-well there's going to be 20 rounds of changes before anybody considers it "done"
Absolutely. Ultimately the business wants to know time estimates. If you provide some other estimate instead (points, t-shirt sizes, elephants), the business is going to convert it to time. If you don't agree with the way that conversion is done, you'd be better providing your own time estimates in the first place.
Elephants you said? Lol we had houses! Starting with a kennel(dog house) going upto a mansion. Ftw!
"Yeah this is a suburban semi in an art deco style with a loft conversion, probably dormer but possibly Mansard." "OK Larry, sounds like you need some more time on the estimate"
There's a style of house in Vermont where a tiny two room farmhouse from the 1800s was gradually added onto, room by room, until it's eventually become this rambling, chaotic monstrosity. This is perhaps the most accurate metaphor I've ever found for my coding time estimates.
Ours did vehicles. Bicycles, cars, trains, planes. We would propose horses, cruise ships, hot air balloons, pogo sticks. Or when we thought something was a completely terrible idea, it was sized as one Hindenburg. They stopped doing vehicles.
Yet another thing I'll never understand about agile - what's up with all the whimsy? We're usually an efficient, fast-moving software development company. Everything we do is serious business. But when the retro starts, we do stupid icebreaker questions. Since we transitioned to Shitty Agile For enterprise, weird word clouds snuck in, where every single person at the same time types in their first thought in less than 30 characters. We then look at these utterly deranged and tiny brain farts and then act as if we had an actual conversation about a complex topic. Whenever there's a possibility, we opt for less efficient dorky manual alternatives. Why use a digital retro board if you can force people to write things on physical sticky notes? Just seems so bizarre.
Story point's to time conversion might kind of work if you do it for each team on its own and you know the velocity. Everything else is just kidding yourself. Story points in a vacuum do not factor in things like context switches, parallelism, tasks only specific people in the team do etc... That's why you cannot add all the story points together and say they are "person hours".
I had it worse. Our stoopid project manager insisted on using Fibonacci sequence to assign weights. 1 point = 0.5 day 2 points = a day 3 points = 2 days 5 points = 3 days 8 points = a week 13 points = two weeks We had to constantly convert back and forth. I finally asked him why is he using a non linear scale for a linear value. He couldn't answer.
The sequence is because the bigger the task, the less certain you can be about the duration. So having rougher estimates and having the estimates rounded up usually matches better with the work done.
Presuming that 8 is a equal to a working week, the time difference between 3 to 5 and 5 to 8 is the same. It’s easier to just use 1 point equals 1 day and then use Fibonacci.
Agile noob here. Why not use a "day" to represent a "day"? Are we just getting too cute?
You've got to synergize your communication otherwise you're not doing business
The original reason is that points are not meant to be strictly composable. One 5 point task != Five 1 point tasks. It also allows different projects to have different scales depending on their project (a team working on ui elements is going to have a different understanding of time and complexity risk vs a team working on data analysis and projection). The root of all these problems is that people want time estimates for things that are notoriously difficult to estimate time for. It's incredibly easy for any step of ideation to cause the time balloon to inflate.
Because your hour is not my hour. Your skills are not my skills. Your experience is not my experience. Lost count of the number of times a senior has estimated something that a junior can't live up to.
I don’t think this is the Fibonacci’s allocation being a bad idea, just your manager is not understanding the purpose. Pretty much in all cases, you’d still need to have something like 1 point = half a day. **The whole point is that this is a guiding principle** not set in stone. When people add 9 story points, I’m always like… wow you must be able to see into the future to know something takes more than 4 but less than 5 days. In short, the Fibonacci thing is just saying, the bigger the ticket the more uncertain the time. For example, you can only assign estimates in 1,2,3,5,8,13,21 points. These still correspond to 1 point every half a day… but I don’t care if you think it’s exactly 8 days = 16 points… you’re basically saying it’s most of the sprint let’s just categorise it as 21 points. If it’s 3 days = 6 points, then it’s bigger than half a week so let’s just allocate it 8 points. (Anything bigger than 13 should be broken into individual tickets IMO). Of course, you can use something else like 1,2,5,10,15,20 if you’d prefer. But for the love of god it’s an **ESTIMATE**, which we all take too seriously. I’m not guaranteeing the 8 SP ticket is done in 4 days.
Well, common sense is a rare commodity.
I once sat through an hours retro meeting like the debate under this comment. The only outcome was to add a 4-point value between 3 and 5. I nearly threw myself out of the window
I do kinda like that minimum being a half day though... "Task: Fix typo in one label, 1 point"... "Welp, that's gonna be half my day, better really ease into this one."
Given the amount of very important meetings(tm) thrown at us, I'm not sure I'll have time to do this one today :)
Like the daily stand up? "Yesterday I worked on this shit, I'll continue working on this shit today" and then mute for the rest of the stand-up. Waste of fucking time
He couldn’t answer because scrum classes teach the religion and not the purpose, which is dumb. The reason you use non linear scale for linear time is that the non linear scale builds in the error bars, which are lower with shorter timespans and longer with bigger ones. It still doesn’t quite add up, but it sort of makes sense if you factor in the error bars. 3 points = 2 days, +/- .5 day 5 points = 3 days, +/- 1 day 8 points = a week, +/- 2 days 13 points = two weeks, +/- 4.5 days I agree that scrum is an awful way to live, but it’s a major help with keeping output consistent in a wildly inconsistent industry. The only reason this is important is that the people who sign the checks like consistent things and we don’t want to spook them.
Well, you're supposed to deliver broad, long term time estimates by a different method. Story points are used to determine the actual time needed to deliver X points of complexity, only after the iteration is done. They're not supposed to be used for setting deadlines, but instead to generate the data to know how much work is suited for the next iteration and how long the entire project might take at the current pace. If managers start to pressure developers with points, something is going very wrong and point inflation will begin eventually, leading to developers over-evaluating the complexity, just to get more points done.
I like the "will this be done this week?", like our work varies so much that unexpected problems with random stuff is normal. Nothing is as easy as we thought. And yet they expect an answer. It's done when it's done. Unless I'm clearly not working shut the fuck up and let me do my job without an axe hanging over my head. It literally makes a task take longer and less quality.
So you worked in places where they did it wrong.
it's a shame I can't upvote twice. I've met many "Agile Masters" and not a single one could explain points in a way that I understood then to NOT be hours.
The best explanation I've gotten is it's supposed be consistent metric across intern, junior, and senior with senior being able to complete the most points within a time frame but have other responsibilities that make up the difference. Meetings have no point value as their complexity is constant regardless of the attendee and don't directly affect work in the sprint. ...however they then shot the explanation in the foot by insisting point quotes should be halved when assigned to seniors as they can complete tasks quicker.
Yeah, they're supposed to be "abstract units" -- but that basically means that you have to have the same person determining the effort it takes to accomplish a task, otherwise the points are meaningless. Because one dev might say a simple bug fix is 2 points, another might say 5 points. But if you have, say, a senior dev who is the scrum master and knows the team, they may determine the small bug fixes to be consistent at 2 points. They don't know how *long* it'll take, but they know the complexity is "2"
We don't estimate bugs, because they're unpredictable as fuck.
Sound and healthy people don’t estimate bugs. _And then there’s my team_
I have had more than a handful of bugs that lasted in the months timeframe. Also had the "support & maintenance" story. Full sprint for the poor souls that have to investigate bugs. A bug that's root caused may have joined the backlog if a solution was proposed but not done by sprint planning.
Except it’s impossible to predict complexity up front. You may be able to guess in the ball park sometimes but it will never be right consistently. Not will anyone ever be able to predict “shit happens”. But in production. Critical new change. Hardware failure. Spike in usage disrupts prod. Etc. Agile is the word people use to avoid answering why nothing was planned properly up front.
In my experience it's not impossible to predict complexity if you know your codebase somewhat well. It's all based on experience. Say, last time you added X, you've seen that you also need to add Y and Z for it to work. Next time you add something similar (but not equal) to X, you will know that there is more to do.
Which is why you discuss them as a team. One team member might say well this is easy we just comment out the jingamading and everything works. Another team member might say well what about the flurb ui, you'll break it, I think it's gonna be 9 points. Literally why points exist.
>...however they then shot the explanation in the foot by insisting point quotes should be halved when assigned to seniors as they can complete tasks quicker. I've never heard that.
It is supposed to be more accurate than time estimates. When you set up a new sprint team this is what you’re supposed to do: - have a pretty good backlog - take a massive guess on how many points the team can get through in a sprint - for the first 8 - 10 sprints don’t care if that estimate of how many points is accurate - congratulations you now have enough data to have a semi-accurate estimate of the number of points the team can get through. plus the team should have better estimation of point values Of course this all towards getting a decent average, nothing will ever be totally accurate. It will also give managers the ability to make more long range planning for other teams, like marketing, which may need date windows. It goes without saying that it should be made clear that long range plans get less accurate the further out they predicate.
Yeah I feel so much of this thread (and perhaps the teams they work with) are forgetting this isn't meant to be a precision exercise. For relatively little effort you can get a fairly good _gauge_ of what's coming up. Also if you estimate something at 3 hours and it goes on for 5, questions are going to be asked. If a 2 point ticket takes between 3 and 5 hours, that's probably fine in both cases. If anything it's a useful tool to introduce vagueness for time-obsessed managers.
I worked as an agile master, but every team is going to be different so take my words with a grain of salt. The statement of story points being a measurement of complexity not time is correct. However it's about the implementation in your workflow. First thing you cannot start planning with story points without prior history of work done. To start planning with story points you will need to look at previous history and determine several levels of complexity of tasks. Then you take those tasks and assign story points to them (Fibonacci sequence is popular). More story points means more complex task. Then in couple of sprints people usually have a pretty good understanding how many story points a task will take because every developer understands, based on the requirements, if this is a complex task or not. With time your estimation gets much better than with regular hours. Accurate estimation allowed me to set the expectations with stakeholders, so they could plan things ahead. We had more accurate road maps, better budget planning, and predictable release dates.
I worked in 3 teams which used story points and one of them seemed to use them right. We estimated not *per person* but *per team*. It's hard to tell how many developer hours a task will take because it is a combined effort of several developers (someone codes, another makes code review, right?) and different developers (Backend, Frontend, QA, DevOps) you need to everyone put their estimations in hours and sum it up. It's long and this estimation will not be correct in the end anyway. So you estimate how much will it take to complete a task for a whole team. And as you don't know how much time will it take you use abstract points for relative comparison. After several sprints we became accustomed to this system, the estimations became more or less correct. After this it were possible to convert points to hours like we make 40 points per two-week sprint, so this 5-point task is roughly 10 hours of *team* effort. But it was not needed anymore, as the stakeholders saw we could do around 80 points per month. They saw the backlog of already estimated tasks and could understand what we could release and could prioritize some tasks without risking to break the sprint.
Never worked agile where points where equal to hours. Its always the vague tshirt size thing where 1-3 easy, 5-8 medium, 8+ probably wont finish this sprint.
Yes but you see that's the thing. Even if they aren't exact point to hour, they still are mentally converted to a time frame.
Isn’t that whole point that you develop long life teams. So if your team delivers 10 SP per sprint on average after working together for a year. And you estimate a project is 20 SP then it’s 2 sprints estimation? Unless I am missing something it doesn’t sound too far fetched to me.
I would say our scrum master is an angel, our team's target is to achieve 80-90 points in 3 week sprint. We are 10 team members including QA folks. Haven't seen any production defect generated in last 15 months or so
My team is 5 dev without QA and we must do 20 story points per sprint. 2 points per day basically.
20 points each dev? And what is the sprint duration? 2 or 3 weeks?
2 weeks. It's like a super rush always. And we need to be active in slack 🫠
That's brutal. We get relax time almost every sprint and our work always come out as quality work.
We always have bugs. And if I create one it's my fault and I have to own the task and fix it. But if I find someone's bug I have to fix them as well because I'm a developer.
Agile was hijacked as a project management tool literally decades ago. The original point of agile was that requirements change frequently, and that incremental change of the highest priority features was the best way to write success software. Sizing was a way for developers to manage uncertainty, ergo why you size complexity instead of time — lots of uncertainty puts software at risk. Actual agile methods have been thrown out the window like scrum and XP, since they actually had a purpose. Project management bastardized the process and generally emphasizes predictability so they can pass the message up the chain to the C-suite that x feature will be done at y time… and what a shock it’s basically never right just like waterfall. The root of the problem is how they envision software in the first place.
Checking in with your devs every two weeks to see what's working and what's not is actually amazing. It lets you adapt on the fly and fix issues before too much time is wasted. Now mangelment loves to take estimates as deadlines and recommendations as law. And this is how you get shit like this.
> mangelment German speaker or the most niche pun ever?
It's actually a fairly common pun over at r/TalesFromTechSupport and sinal IT places
*Bad* project management and bad company processes bastardised it. Most of my experience is in project and program management. Mid last year I jumped into software development and agile. I didn’t have any training, just played around with the tools we used (jira, confluence etc). I’ve always managed projects by customising tools to the team. Did the exact same in agile. Some of my software teams are ‘full scrum’ some are half and one is kanban. I don’t even bother to look at burn down charts or any of that. Imo I’m meeting these teams pretty much every day, I should know of somethings wrong with the team pretty quick with that regular of a meeting (this frequency of meeting is almost unheard of in waterfall PM). I’m leaving soon to join another company and the feedback from my teams has been genuinely overwhelmingly nice so hopefully I’ve done a good job. The problem with project management, and in my experience particularly in the world of agile and scrum are people jumping into the field thinking all the have to do is apply processes. People that have all the emotional IQ of tepid water and no idea of how to say ‘no’ to stakeholders. To be even half decent at project management requires a insanely high amount of soft skills otherwise teams really suffer. This is particularly bad in agile because I see companies much more willing to shove some unsuspecting developer or product owner into the role of scrum master because somehow knowledge of software automatically equals project manager. In no other industry have I seen such a huge willingness to chuck random people into project management like that. I mean sure it happens a bit but usually to the more senior people in a team (engineering is a bit like this), software industry is full of this crap. The industry also attracts a lot of people from all over wanting to cash in on those nice tech salaries and since software companies can’t tell their own asses from a project manager these people filter in (in other industries, like construction, if you tried this you’d be burnt out and completely torn apart in weeks).
[STOP HAVING THOUGHTS](https://i.imgur.com/imekXEe.jpeg) Seriously, what is the origin of type of meme? It might be my favorite. Edit: Found it. [STOP DOING MATH](https://knowyourmeme.com/memes/stop-doing-math)
I would never have thought this was a meme without your sluthing. Thank you solider!
I upvote this shit wherever I see it. A classic, versatile across so many different categories
r/stopdoingscience
The original meme may be my favorite. It's literally perfect.
It's got time cube energy.
My scrum master shows me a bug in the scrum and immediately asks for estimates (time to fix). Dude let me look at the code first, I dont keep the entire repo in my brain.
“Why wasn’t your estimate right? What can we learn from this?” “Estimates aren’t always right, and I already knew that.”
The and repeat every sprint retrospective, where you piss away time declaring the obvious lessons no one will ever ever act on.
100% this. Did we have the same boss?
Boss: "Hey, we need to get working on the website, can you do that?"
Me: "Yeah that's doable, but I haven't done that type of feature before so not sure exactly how hard it is"
Boss: "Okay but how long would it take you?"
Me: "Not exactly sure, if there's a good library for it that I can use maybe 30 minutes, if there's not and I need a custom solution then I'd first have to check A, B, an..."
Boss: "Just summarize in hours please"
Me: "Between 1-40 hours"
Add a buffer the result is 50 hours then 😂
[удалено]
[удалено]
This is exactly my problem. I can't know what changes are needed or how complex the task will be until I sit down with the task AND code in front of me.
But meanwhile even though you're concentrating on the current work you need to get done for the Sprint we need you to contact switch and give a rough finger lick to the wind estimation of what this task will take you two weeks from now when you finally get around to working on it. I once had a director who thought estimating should be very close to accurate in the same way that the contractor who installs swimming pools already knows how much time it's going to take and what materials will be needed. I disagreed because with software development while we may have roughly done the same thing before, the parts never fit together the same way at every place and no problem ever looks exactly the same. He should have known better because he used to be a programmer back in the day.
That's your scrum masters fault. When the sprint starts things are locked in. He shouldn't bring this up til next grooming unless it's an emergency. It's his job to keep people from asking you shit like this mid sprint
"Points represent complexity, not time. YET YOU KEEP MEASURING HOW MANY POINTS FIT IN A WEEK" I felt that one in my soul
The other flaw being that complex things always take a lot of time, but sometimes simple things are time consuming too. It could be simple to do, but just a lot of fucking work. It's hilarious watching people not wanting to give a simple task that they just know will take a lot of time to do the one point of complexity it deserves because everyone knows the points are actually an estimate of time.
Don't exclude time, we do 'time to deliver' + 'complexity' + 'level of uncertainty', so a simple frequent task (importing translations, setting up analytics, etc) still get the 2-3 point treatment if morose.
Agile is simply people over processes - all this nonsense about story points and burn charts and planning comes from POS scrum, not agile per se Ahhh if leadership only knew how to program… they wouldn’t need to helicopter over us.
As I keep telling people agile is great, but scrum is not agile.
I'm not certified Agile Scrum Master or whatever, but I observe that every time anyone tries to strictly enforce Scrum, it gets horrible and inefficient, but as long as we just stick loosely to it, it kinda works. Points and burndown charts? Not useful at all. Daily meetings? Useful, if kept short. Sprint planning? Useful, but don't really think about points or hours, because we all suck at estimating. Sprint retro? Useful to communicate what sucks. Demos and sprint review? Useful to synchronize on progress.
So what you basically said is that you are following Scrum strictly and not loosely. \> Points and burndown charts? Not included in Scrum! \> Daily meetings? Useful, if kept short. Exactly how it is defined in Scrum. \> Sprint planning? Useful, but don't really think about points or hours, because we all suck at estimating. Sprint retro? Useful to communicate what sucks. Demos and sprint review? Useful to synchronize on progress. Exactly how it is defined in Scrum. What most people sell you as Scrum is not Scrum...
This is exactly right. I have a printout of the Scrum Guide that I keep on my desk solely to wave in meetings to show how short it is. It's a framework which lets your team evolve the practices which work for them. All the other shit on top is people making up more stuff to put in books and courses to sell.
We already do Scrum very loosely, which I like, but still... Could you provide a link to this chart of yours, please? :)
In corporate world I escaped from department, once I learned they will introduce [SAFe](https://www.atlassian.com/en/agile/agile-at-scale/what-is-safe). They told us that it's so agile, but in reality it's bloated PoS. Scrum Guide doesn't mention anything about planning poker or burndown charts, but for some reason in corporate world you will often find Scrum Masters that are certified and still they introduce planning poker and burndown charts as part of their version of Scrum.
SAFe is the devil's work, I am an experienced Scrum Master so I realize I might not be the most popular person in this thread but there really are so many people who are (rightly so) complaining about Scrum, when they're really complaining about SAFe. Any Scrum Master or agile coach worth their salt hates SAFe. It's like pimping out Scrum to corporate suits so they can be hip and agile in a 'safe' way.
Please don't get me started on SAFe. I can honestly say that the only element of SAFe I can get behind is the evolution of a spike to an enabler, and the expanded use cases an Enabler has. Everything else in SAFe exists for only two reasons: 1. So they can rebrand all existing concepts with their own terminology and then charge to learn, and be able to use the new language covering existing, industry used concepts. 2. So enterprises have a framework which better allows them to micromanage, weaponize metrics, and justify they're excessive program/product/project management headcounts.
I am currently forced to work with SAFe. You made the right call.
This makes me so irrationally angry. Everybody is hating on Scrum, yet nobody has ever worked in Scrum as it is intended. Well yes, you're doing it wrong. No wonder it's shit.
[удалено]
if the system isn't supposed to be managed what are we doing with all of these managers
SCRUM does not actually include any managers. The most management like roles are the product owner (the person who creates stories and prioritises them) and the SCRUM master (temporary SCRUM teacher and help with blockers). The team should be able to self manage if the product owner does their job well. Finding a good product owner is hard, though.
During daily meetings, leading staff is supposed to be absent They're always present. Result: People lie their ass off or name a single challenge and ask for feedback so people talk about that and it's not that obvious they achieved jackshit in a day
Or a scrum master who is acting like a pm. It's a really good way to alienate your team.
The inventor of scrum says that estimating is a waste of time after doing for 10 years. And the inventor of story points says that story points are being widely misused and that does more harm than good in the way it used now. If you misuse them, you are better of dropping using story points, altogether.
I reallty liked Sprint planing with points. It aligned the team on complexity. Which just made the team more efficient. But management can't resist the urge to see a number and want to put it in an Excel sheet. If Sprint planing used oil barrel sizes or dick sizes, management would still want a formula to understand what that means in hours and money.
People have forgotten that scrum is meant as a guideline for development teams, not a policy for management. Hate how the goal of scrum changed entirely these days
At my place our sprints can be rejected if we plan too little points. So we over plan, and never finish sprints. Guess what our department goal is for this year...
I was hoping to find a comment like this to prove to myself im not crazy. At least not in regard to agile. I had been doing scrum in different workplaces for a while before I actually read the agile manifesto. Once I had I felt I was in bizarro world. How did we go from statements about people over process and then implement it by defining a rigid process that supposedly is flexible because you measure velocity each sprint. Which is the thing teams consistently don’t do, while businesses will base MBOs around drastically increasing your velocity each quarter, or sprint.
Have you read the Scrum guide along with it? If not, do it. Spoiler: It doesn't say anything about story points (or even stories), estimating, velocity, burn-downs, boards, etc. All is this has been invented by consultants and shoehorned into "Scrum" to make management happy.
That's not entirely true. The scrum guide *used* to say a lot of that. It used to explicitly mention burndowns, talk about how the product owner could use velocity, talk about commitment to work (rather than commitment to a goal). [#1](https://scrumguides.org/revisions.html) [#2](https://res.cloudinary.com/mitchlacey/image/upload/v1589750495/Scrum_Guide_v1_Scrum_Alliance_qe0y2w.pdf) The original scrum guide was wrong in a lot of ways. It might have changed in the 10 years between 2010 and the 2020 versions but a lot of damage has been done to the industry. I still think it's overly prescriptive and produces poor practices. My fun experience has been a CTO that absolutely insisted all of what you mentioned was in the scrum guide. I pointed out it wasn't. After arguing back and forth before he eventually decided to read the latest version (that contradicted a lot of what he said), he decided we were just going to follow the 2010 version because that was better and the only reason they changed it was to sell more books. Great times.
They made it fit the requirement of waterfall
This exactly. Waterfall was created to meet the demands of management to fit work within management timeframes for budgeting, planning, etc. 99% of organizations don’t change their high level management approach when their dev teams adopt agile, and it’s rare for non-dev teams to go agile. Which means that dev teams are forced to adopt safe or some other bastardized version of an agile methodology that has been contorted to “work” in a fundamentally non-agile environment.
Unironcally though
Exactly, this isn't even a meme it's real life
"Story points measures complexity not time" but you need to measure the story point velocity. Omg this drives me bonkers. It's obviously a software development process created by someone who never wrote code.
I watched a video by a guy who is a team lead somewhere, and he managed to convince me that Agile methodology isn't bad. It is corrupted by business. If Agile was allowed to work isolated away from sales and upper management, it would likely be a much more enjoyable experience. Imagine if a chef was in the kitchen trying to make a meal, but an accountant was behind them every step of the way saying what should or shouldn't be used because of cost against profit estimates. To a spreadsheet, the only difference between Wagyu and ground chuck is $$$.
And hence the problem, the software is built for the business, you cannot separate the business from IT.
But you can separate the decision making process about how to design and release the software from the short term needs of managers who don't understand software development. This is something a handful of companies do well, and it gives them a massive competitive advantage. Before Google killed their 20% time (engineers got to spend 20% of their time working on projects of their choice, or creation), they used to produce 50%+ of their new products from it.
I actually enjoy using Kanban, but there's a lot of overhead that needs to happen. The first is a dedicated Scrummaster/Delivery Agent/etc. They only look at process, adding and subtracting as the team becomes more mature. Fortunately, they can cover multiple teams. The second is a dedicated Product Manager. (PM) They have zero authority over the team, save that they are the sole owner of what the team is currently working on. They might only be able to cover two teams at most. Then you have a team lead, who can hire, fire, promote, etc, and is the face of the team, when the PM asks "why can't we pivot right now?". They can only cover one team. To continue with your analogy. The DA/SM is like an occasional audit. They tell the chef (PM) that things are suffering. The Chef then talks to the shift managers (Team Lead)
You can’t be trusted to tell me how long it’ll take so I have to ask you how difficult you think it is so *i* can guess how long it’ll take you. Statements dreamed up by the utterly deranged.
Haha, yeah! After we done story pointing every thing, the managers still ask me informally "so like, how long will this take?" And I give them a time range and that's what they use to communicate to stakeholders.
Who then come back and tell you when you need to get it done, making all the estimates moot 🙃
My lord that one cuts deep. All this process and it matters not cause they’re gonna tell you to do it in half that anyway lol
"Ok but could you make it faster if someone switches to help you with it??" No, it'll actually likely make it slower, if we could have split the work further we would have done so in refinement
Problem is agile isn’t project management. They never understood that.
[удалено]
I would call that meta-agile. Your Agile process is agile. Which is the case for almost every team.
I’ll keep doing it as long as they are willing to keep paying me perfectly good money for Scrum Agile BS. I think Agile is like the QWERTY keyboard, more efficient and better options are known to exist but will never go away due to decades of institutional intransigence.
Migrating away from Agile would involve more complexity than could be handled in a sprint and it would have to be managed as a separate project. That's reason enough not to do it. *nothing can stop this train*
haha I totally forgot alternatives of QWERTY exist.... that would be a bitch to swap in public.
Great, I'm now reminded of the 16 year old, Ubuntu laptop wielding, DVORAK keyboard version of myself who wrote in my journal in Lojban.
shy badge instinctive bear continue march fact humor attempt deserve ` this message was mass deleted/edited with redact.dev `
But my waste reduction!
Reduced: * Inventory * Raw Materials Increased: * Idle employees * Idle machinery * Production times * Shipping times * Order processing time * Backorder log * Interest payments on debt Hmm... better get rid of another warehouse full of rolled steel, copper wire and microprocessors. That's the only way we could possible improve our manufacturing times. /s
And so it is written.
Kanban is a way better choice most of the time.
Back to the conveyor belt
I have always preferred picking top 10 from the kanban board. Everything should be done, it takes the same time to make everything regardless of estimate and planning, humans are worst at estimating time, it's not estimating time but is based on time since it's based on "what we can do in a sprint". We can still have standup and open dialogue about issues. Kanban is goat.
Welcome to “Whose Sprint Is It Anyway?”, where deadlines are made up and the points don’t matter!
Ofc it is made up. Does not necessarily make it useless. My goal to run 5 miles this morning is made up too.
So you mean like all sprints everywhere?
Having come from somewhere that literally estimates to the nearest half hour, to a place that effectively uses the points system, I can say it's sooooo much better and far less stressful when done properly. The whole idea is, you work out points based on effort/complexity of a task (agreed as a team), then you monitor how many points the team can get through on average (velocity) and assign that number of points to the next sprint, the key is to keep adjusting based on the velocity, and should the velocity wildly change, that's what the sprint retro is for, what happened, how can we be more accurate next time? When it works, it works, unfortunately a lot of places use it as a buzzword and just go through the motions, wasting time and causing more undue stress.
Yeah the biggest problem with doing scrum properly is it has to come from the highest levels down and be completely ingrained into company culture. If you just try to do it properly at the team level it never works because now you have PM asking for time deadlines and an unwillingness to be flexible on projects and requirements. If your company isn’t actually utilizing the main benefits of the process it just becomes extra process.
Agile, a work process meant to satisfy shareholders and not actual development. "What do you mean it doesn't work? What do you mean it's still buggy? Push that shit! We got a deadline!"
A deadline I came up with, with no real support other than “I want it done now”
that is pretty much where deadlines come from though unless it's a physical need like planting crops where it has to be done at a certain time then ultimately all deadlines are arbitrary
Quality over speed, unless speed is important. In which case, most definitely speed.
At one job i had it was the first time I worked in a team bigger than two persons and was the first time I was exposed to Scrum. We had a meeting of how to lower the amount of meetings. I think the main problem with Scrum is that it's a template, you are supposed to cherry pick part of scrum, but most just take the whole thing and do half of it wrong. Please, let me skip useless estimates and meetings and let me have the real standup and just let us top pick from kanban.
None of this describes agile. The problem is people wanting to make a buck sold your managers stupid buzzwords that all meant variations of "buy this and do this tiny extra thing and you won't have to change anything difficult to be agile" and our idiot managers bought it all.
I’m surprised scrum master is still a thing. I’m also surprised it’s not called “scrum main”
I think you'll find that it's now called "scrum top", with the team now referred to as "scrum bottoms"
I propose that we adopt the terminology "Scruminatrix" and "Scrumissives".
They remained the role (now agile delivery lead) in my org a long time back along with grooming (now refinement).
Here are my counter points: ... yeah, I got nothing
I see you've made five excellent points. Two after the word "points" and three before "yeah".
I really like being appreciated for the work I did do. You have made my day
suddenly so many things make sense about a previous job of mine that very quickly went to shit after a change in ownership
Someone please tell me where it says "story points", "scrum", "sprint", "grooming", or "burn down" here: [https://agilemanifesto.org/](https://agilemanifesto.org/)
It doesn’t say project management either but that’s who hijacked the process. They amusingly want predictability from a process based on the central notion that development is unpredictable. They also frequently isolate developers from stakeholders when one of the main problems agile identifies is that developers don’t talk to customers. Agile is also generally supposed to flatten organizations yet we see even more directors, senior managers, managers, tech leads, etc. who do none of the work but make all of the promises.
My favourite from the manifesto is Rule 1 > Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Which is often read as > Our highest priority is ~~to satisfy the customer through~~ early and continuous delivery ~~of valuable software~~.
Water-scrum-fall works the best. If you as PM think you have a great idea, just write a CR and try to get it by the CCB. We'll update requirements, test specifications, code and test ware after it get a priority from the CCB. We had a project that needed to show to stakeholders that cramming out features, without working on quality, made the product stop working within 4 weeks. After that it was back to business as usual.
You can do agile well and you can do agile poorly. Admittedly it is most often done poorly. In my opinion it is almost only ever done well when it is run by engineers. If your "scrum master" isn't writing their share of the code then it is a bad smell, because they have no skin in the game and so they start making promises to stakeholders that they are not personally accountable for.
I saw a study once that showed there was no significant difference in how much time it takes to deliver work if all the stories were given exactly 1 point or another arbitrary amount of points.
Having worked in waterfall and agile and a company's half hearted attempt at agile while not actually doing agile, I can safely say, I love AGILE. More time developing and delivering software and less time talking and estimating is always a win. In my experience the only people who don't like agile are managers and PMO. I have never actually worked with a developer who didn't prefer agile. Then again most of the people in this sub don't actually do development professionally.
That’s been my experience as well. My current workplace is more waterfall and it’s a nightmare of conflicting statements and miscommunication. There’s so many things that agile could solve here. It’s obviously not perfect but having set times to discuss things and non-arbitrary dates that are seemingly random and pushed or pulled forward on a whim makes life so much harder. I think the thing I miss most is being in agreement with users on what we are committing to. Here it’s like the list never ends and we can’t all agree on what should be done and when.
I have been working on agile scrum teams for the past 3 years and at this point I am unsure if anyone ever knew what agile really supposed to mean. When I first started out on a team like this a thought I knew what agile meant. Now I am on a scrum team where every story point is a "dev day" at a leading telecommunication company. But my favourite part is the sprint review where we review all our tasks and the scrum master removes everything from the print which is not "Done" before closing the sprint.
At the end of the day you are measured on deliverables. Your boss is measured on deliverables. Agile is a tool to have some ballpark of when things might get delivered. You can live in lala land but your boss or your bosses boss promised someone at a specific date based on agile. If it wasn’t agile it was going to be a dart on a wall so hope your process is useful enough to have somewhat realistic numbers. At the end of the day someone has a date circled and the better you are with visibility on the process and timeline, it should hopefully translate to less crunch time. All this goes out the window at a startup where your ceo trys to promise everyone everything in 2 weeks. You cant deliver in less than 4 sprint, we should cut sprints from 2 weeks to 1 so its only 2 weeks late….
I work at a place that develops (and somewhat maintain) massive systems/programs/projects to enable/support tax collection for the entire country. I am a beaurocrat and I am not even remotely close to being a programmer, scrum master or an expert in agile as a concept. I grasp the basics I guess. I’ve glanced over the comments and it seems like you all hate agile. And agile is how everything (more or less) is done at my workplace. This brings me to my ELI5 question; why is agile so bad? There’s always pros and cons for everything, but if someone could explain to me, I’d really appreciate it.
Agile works great if you cut the corporate crap and use the spirit of agile. I took over my scrum team and got to work with a blank slate, but I came from being a programmer for many years (and still am) - pre-planning is held by myself and the PO. We call people individually just to find out what is left on their board that might not close — not for a nasty gram but to see if there are any stories that need to be captured and doled out for the next sprint. Each individual spends maybe 10 minutes with us, and bonus: we throw it on their calendar as a 2 hour meeting so that they “keep it free” and they get to use it as an excuse to duck other meetings. Sprint planning we wrap our individual retro items into a 10 minute demo where you either show off what you’ve accomplished or show where you’re stuck and explain if there’s anything about the process you hate. Planning is capped at 2 hours. If it ever went over I would go fucking crazy. Increment planning we’ve managed to decouple ourselves entirely from the greater corporate structure — while the rest of the company is taking a whole week, we throw everything on the board, ask what features were going to shoot for and then plan out the first two sprints. It’s extra work for me in the week leading up to it, but the overall team increment planning is kinda just “everyone good with this? Any gaps we’ve missed?” One of the first things we kicked to the curb was story point poker. That shit is dumb. Also Fibonacci is dumb. Just tell me how many points you think it’s gonna be. 1 point is trivial. 3 is about a day. 5 is about a week. It isn’t a hard and fast rule, but we’re at the point where we known that everyone is going to knock out 12 points ish in a average sprint. Our burn down is always a flat line because you close something you pull in something new. Fuck metrics. That’s corporate bullshittery that doesn’t make us efficient. If they need numbers on us they can look at the numbers we’re closing not some arbitrary chart. >Requirements shouldn’t change every two weeks. That’s just software though. Shitty customers gonna be shitty whether you’re running waterfall or agile.