41–50 of 388 posts
Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible
I am not saying it will get things perfect, but it will be an improvement.
The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders. I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day. > There is back-an…
>but this is the issue addressed with planning poker. It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given.…
Earlier quoted context omitted.
That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
Relative sizing is still an estimate.
> They're for re-arranging the priority of stories and deciding which ones to do or not.
Hard disagree - that's what priority is for. Story points are an _estimate_ for how much we can do in a period.
Earlier quoted context omitted.
>but this is the issue addressed with planning poker. It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given.…
I mean it is literally the issue that planning poker addresses - identify differing expectations without influencing the initial estimate. People can then totally ignore that, and ignoring something makes it pointless, but that's true of literally anything. It identifies a lack of a shared understanding of the task. Or framed differently, it identifies when you probably all have the same expectation and you can move…
Or we can dive into technicalities where it technically does solve the issue but does it poorly, and just happens to be better than any other system we know (also questionable).
If developers did not approach projects with the goal of adding acronyms to their resumes and infuse every project with the latest cargo cult du jour it would improve the ability to predict timelines. Pick boring technology, that the team is already comfortable with, when possible. Keep the teams as similar as possible, Keep running projects the same way, when possible I am not saying it will get things perfect, but…
Never reduced an estimate (without change of scope) in my whole career. Didn't do me any harm.
"Your estimate, your problem"
Rubbish metaphor
Earlier quoted context omitted.
Out of curiosity, how did you came out with this formula? What’s the math behind it?
Crude estimate based on some self evident truths: Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow. New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
1975: Fred Brook's wrote[1]: “The bearing of a child takes nine months, no matter how many women are assigned.” Can't get better than this [1] https://en.wikipedia.org/wiki/The_Mythical_Man-Month
"The late preterm singleton rate rose at an average annual rate of 2% each year from 2014 to 2019 (from 5.67% to 6.32%). The decline in the late preterm rate between 2019 and 2020 (6.32% to 6.30%) was not significant."