Discover and read the best of Twitter Threads about #noEstimates
Most recents (16)
A developer (in a team or a multi-team environment) can never know how long it takes to develop a feature a #NoEstimates thread 𧔠explaining why...
There are many reasons why Estimates can never work (as input to reliable, and money/time sensitive decision making). But there's one that goes against the very basic beliefs we have in software development #NoEstimates
The basic premise that estimates rely on is that a "Developer" can reliably know how long it takes to develop a feature (let's call it that for now) that they have been presented with in the form of a spec or user story #NoEstimates
There are 3 critical logical fallacies that people make when they think about estimates. And they are quite easy to debunk too! A #NoEstimates Thread...đ§”
The First: people think "better" estimates get you more predictability. If this were true, all transportation systems in the world would spend MILLIONS on estimators! Instead, what they do: measure, repeat.
They measure past performance, and assume similar future performance. A great example of this is the drawing of bus/train/air traffic timetables.
In #Agile software development, this can be easily done by measuring cycle time for Epics/Features/Stories, and using that to plan!
In #Agile software development, this can be easily done by measuring cycle time for Epics/Features/Stories, and using that to plan!
Why Story Points are Trash - a thread đ§”
1. Story Points are Subjective: Different people may have different interpretations of a particular story point value, leading to misaligned estimates and potential discrepancies in the overall estimation process. #estimation #noestimates
1. Story Points are Subjective: Different people may have different interpretations of a particular story point value, leading to misaligned estimates and potential discrepancies in the overall estimation process. #estimation #noestimates
2. Story Points are Fragile: Changes in team composition invalidate relative estimation efforts. WIP impacts relative estimation efforts. Hidden dependencies impact story points.
3. Story Points are Hard to Define:
-Mike Cohn uses time: mountaingoatsoftware.com/blog/story-poiâŠ
-Ron Jeffries uses days:
-Bloggers say capacity, effort, risk, time: peterkretzman.com/2018/10/24/quoâŠ
WHICH IS IT!??!??!
-Mike Cohn uses time: mountaingoatsoftware.com/blog/story-poiâŠ
-Ron Jeffries uses days:
-Bloggers say capacity, effort, risk, time: peterkretzman.com/2018/10/24/quoâŠ
WHICH IS IT!??!??!
The next time youâre prioritizing, create estimates first! Let me explain why:
(1/n)
(1/n)
Let's say you are trying to decide between which of two tasks (let's call them X and Y) to do first. Doing X saves $2000/day and Y saves $100k/day. Which one would you do first?
(2/n)
(2/n)
Instinctively, we feel compelled to do Y first. After all, its âimpactâ is 5x that of X. But thereâs a fallacy lurking here (Iâm not sure if it has a name đ€· ) - we havenât accounted for the amount of effort involved in doing X or Y.
(3/n)
(3/n)
There are so many different opinions about cost estimations in software, and many of these are rooted in estimates being used as measurements, targets or commitments. I want to clear up some misconceptions regarding estimations.
A thread đ§”1/n
#NoEstimates #ProEstimates
A thread đ§”1/n
#NoEstimates #ProEstimates
The first thing we need are some definitions. One major driver of confusion are the various interpretations of the words "estimate" and "estimation".
An estimate is "an approximate calculation or judgement of the value, number, quantity, or extent of something". 2/n
An estimate is "an approximate calculation or judgement of the value, number, quantity, or extent of something". 2/n
This definition does not mention *what* will be estimated and *how* these estimates will be used. And that's normally where the arguments start, since everyone is making different use of them.
I'll try to summarize the most common uses of *what* is estimated first. 3/n
I'll try to summarize the most common uses of *what* is estimated first. 3/n
Esse tuite atraiu comentĂĄrios legais e me lembrei de um movimento muito interessante de quase dez anos atrĂĄs que imagino que muita gente, principalmente quem estĂĄ na ĂĄrea a menos tempo, nĂŁo viu: o #noEstimates.
Fica a dica para entenderem o significado de codar sem estimativas.
Fica a dica para entenderem o significado de codar sem estimativas.
JĂĄ trabalhei em projetos que em algum momento transicionaram para nĂŁo usar mais estimativas. NĂŁo Ă© rĂĄpido, demanda maturidade do time e da empresa, mas o resultado Ă© muito bom. Ă possĂvel ter previsibilidade sem estimativas e o resultado Ă© ainda melhor do que com elas.
E o projeto ainda ganha uma melhoria de produtividade, jå que estimar toma tempo (e não é pouco). Além de nenhuma pessoa codificadora gostar de fazer estimativas, eliminar essa atividade aumenta a felicidade do time e consequentemente diminui o turnover do projeto.
We have been practicing #NoEstimates for 8 months. Here are some learnings đ
We started in a legacy code in which the people that created that service left the company some months ago and we needed to deliver some critical features
No business knowledge, no technical knowledge, a mess ahead
Business: Will you be on time?
Me: No clue yet, give me 2 weeks
No business knowledge, no technical knowledge, a mess ahead
Business: Will you be on time?
Me: No clue yet, give me 2 weeks
Should we go for all the work for 2 weeks, analyze the Job to be Done and come back with an estimation?
We had a very tight deadline, 1month and a half to deliver
We had a very tight deadline, 1month and a half to deliver
#NoEstimates, un mouvement hĂ©tĂ©rogĂšne et controversĂ© lancĂ© en 2012 sur Twitter đź
Le sujet vu par @ddreptate dans un meetup organisĂ© par @ByondSM đ§¶
Le sujet vu par @ddreptate dans un meetup organisĂ© par @ByondSM đ§¶
âOn est mauvais Ă estimer (+ câest gros â on est prĂ©cis)
âProcessus fastidieux
âDĂ©tourne de la crĂ©ation de valeur (focus coĂ»t vs. valeur)
âCelle-ci vient de lâimplication des personnes et de la capacitĂ© Ă apprendre rapidement dans un monde VUCA (rien de mĂ©canique ou identique)
âProcessus fastidieux
âDĂ©tourne de la crĂ©ation de valeur (focus coĂ»t vs. valeur)
âCelle-ci vient de lâimplication des personnes et de la capacitĂ© Ă apprendre rapidement dans un monde VUCA (rien de mĂ©canique ou identique)
BIAIS COGNITIFS, une des raisons principales pour mal estimer
âBiais dâancrage: on va tjrs rester figĂ©s sur une 1ere info, on sera influencĂ©s par ça
âBiais de confirmation: on donne + dâimportance aux infos qui vont venir confirmer nos croyances
â...
#neuroscience #NoEstimates
âBiais dâancrage: on va tjrs rester figĂ©s sur une 1ere info, on sera influencĂ©s par ça
âBiais de confirmation: on donne + dâimportance aux infos qui vont venir confirmer nos croyances
â...
#neuroscience #NoEstimates
Thanks to @DrAgilefant and friends, just got my hands on a thesis that shares some enlightening insights into how common and impactful estimation errors are #NoEstimates
I will be publishing more of what I read in this thread.
I will be publishing more of what I read in this thread.
"Outliers are so frequent that the noise drowns out the signal in the data"
In other words: even if you have data from "actuals", you don't really know if you will be late because the outliers are only visible too late and have a huge impact on delays
#noestimates
In other words: even if you have data from "actuals", you don't really know if you will be late because the outliers are only visible too late and have a huge impact on delays
#noestimates
Kmart may have gone bankrupt (at least in part) due to a failed 1.4bn USD IT project.
One more case where estimation, did not - at all - save a company. Indeed, the errors were so large (both business estimates and SW estimates) that the company went bust
#NoEstimates
One more case where estimation, did not - at all - save a company. Indeed, the errors were so large (both business estimates and SW estimates) that the company went bust
#NoEstimates
Estimer les dĂ©lais/coĂ»ts de dĂ©veloppement d'un logiciel dans le dĂ©tail est une perte de temps et d'argent. Les estimations sont toujours fausses du fait de la nature mĂȘme de l'activitĂ© de dĂ©veloppement/ingĂ©nierie : rĂ©soudre des pb uniques âŹïž #noestimates
alm.developpez.com/actu/293707/ChâŠ
alm.developpez.com/actu/293707/ChâŠ
D'ailleurs Ă le sujet des estimations dans l'IT, je ne saurais que trop vous recommander l'excellent talk du non moins excellentissime @f_leguedois : "Cessons les estimations" âŹïž #noestimates
leguedois.fr/cessons-les-esâŠ
leguedois.fr/cessons-les-esâŠ
Dans la mĂȘme veine il y a aussi le fameux livre de F. brooks : « le mythe du mois homme », un essai trĂšs pertinent la gestion de projet dans le gĂ©nie logiciel Ă©crit en ... 1975 ! C'est de ce livre que vient l'adage « Neuf femmes ne font pas un enfant en un mois » #noestimates
I've noticed people argue for #NoEstimates in a bunch of different ways. Here are some:
Size everything about the same and count them, it'll give you just as good results as estimating.
Split stories as small as you can and then count them, it'll give you just as good results as estimating.
So I was thinking about #noestimates. I'd think we could agree that IF estimates were not needed, we would not use them, because waste. (If not I have something interesting to learn.) And WHEN they're not needed, we'd not use them, I should think?
/1
/1
Now I want to suggest that estimates are /always/ waste. They are not product (I hope) so they are automatically waste. We should want to get rid of them on those grounds.
/2
/2
Now I am somewhat bemused by people actually arguing FOR estimates, rather than saying "well, they are waste, but unfortunately they are often necessary, so we should be good at them". Maybe someone will explain that to me. But that's not my point.
/3
/3
@johncutlefish Iâve managed software development with no estimates. I donât see how âwhy estimatesâ makes sense in that context. #NoEstimates clearly states that Iâve worked without estimates. Like saying âGluten freeâ vs âWhy gluten?â.
@johncutlefish Or saying âCoke Zeroâ vs âWhy Coke without sugarâ. Coke Zero means this drink has #NoSugar. In this context it would be a bit nonsensical to say to say âthis drink has Why sugarâ. It can have no sugar, or less sugar, or the normal amount, or even extra sugar.
@johncutlefish Once the #NoEstimates hashtag started growing in usage I have used it as marker for a bigger conversation: âLetâs talk about why we do the things we do, with particular attention on the things we do without questioning or verification as to their benefit.â
Trying a new angle for teaching story slicing, one of the biggest struggles for teams attempting #agile ways of working and arguably the most important practice to understand, given we are trying to deliver value to customers in very short cycles. Read on if you are interested.
The way I see it, there are 3 levels of story slicing, each of which is beneficial and necessary to be able to deliver shippable increments consistently in 2 wks or less. I am currently calling them Capability Slicing, Functional Slicing and Implementation Slicing. What are they?
Capability Slicing is the narrowing of a broader capability* into more precise ones, each independently valuable and implementable and, by necessity, smaller in potential scope.
*The story of enabling a human being to achieve something they cannot currently achieve
*The story of enabling a human being to achieve something they cannot currently achieve
Okay. I didnât mean to say everyone wants a one size fits all solution - but please understand that many seem to think that itâs that simple.
1/
1/
Iâm not proposing that we need an alternative to blink estimation.
If we have a need to make the sort of decisions that blink estimation can try to inform - then there are plenty of techniquesxpeople are using. If they work well, then simply use them.
2/
If we have a need to make the sort of decisions that blink estimation can try to inform - then there are plenty of techniquesxpeople are using. If they work well, then simply use them.
2/
What I seek is alternatives to the sort things we currently believe is important to decide.
To me, the important consideration, and the discussion that led to the #NoEstimates hashtag, is about why we limit our ourselves to decisions that require estimates.
3/
To me, the important consideration, and the discussion that led to the #NoEstimates hashtag, is about why we limit our ourselves to decisions that require estimates.
3/
I got rejected for a role I was hoping for today. I did 3 interviews with the company. The feedback on where it all came undone was that my view of estimates and roadmaps didn't sit well.
I am really struggling with what to do with this feedback. The company told me, several times over, that they were trying to be more agile.
When I pressed them about what that meant, they said they wanted to enable ownership and empowerment within teams.
