#noestimate — Public Fediverse posts

y a ma conf sur le #noEstimate dispo ici . #agile https://www.youtube.com/watch?v=4ogAuN12n7o

J'organise un meetup #agile / #extremeAgilite !
C'est sur le #noEstimate et c'est moi qui organise !

Plus d'info et inscription ici : https://forms.gle/pGDhJCFC43zxj6aP8

Faites tourner !

📆 RDV le JEUDI 26 Février à 19 h au 34 avenue de l'opéra - 75002 Paris
🛗 A l’accueil, donnez votre nom puis 4e étage
🍽️ Un buffet (pizza ! 🍕) sera prévu !

Mon dernier article sur les estimations à l'échelle dans le monde.
#agile #noEstimate
https://www.linkedin.com/posts/thomaslouvigne_hi%C3%A9rarchie-des-estimations-malaise-%C3%A0-activity-7354140753008173056-SJVF?utm_source=social_share_send&utm_medium=member_desktop_web&rcm=ACoAAAEjteEBnQDaJ7s-6BaKejeaE5Sf2aeqQyM

The mental gymnastics people do to explain their estimations are really stunning. Most use this complexity metric - with is plain bad as we don’t have a proper definition of complex.

I’d argue the only interesting and measurable data is how long it will take to implement something. Everything else is just fantasy.

#noestimate

Published some notes on #noestimate

https://thinkinglabs.io/tags/noestimates

@yellowbrickc Thanks a lot for this session. I don't know if you mentioned it but how long time it took to onboard everyone in this very diverse team? Especially thinking about the non tech people.

I loved the trick about story points :) Put random numbers until they stop talking about it :) It might actually be the the best advice for #noestimate adoption. If you are doing no estimate don't talk about no estimate.

@lunivore I have estimated things I understood , but never done previously & my estimate was bang on. I have stopped even guessing for "process or technology is new to me". A #NoEstimate is more precise and correct than WrongEstimate.

To my #Agile peeps, how do you manage to identify Stories that doesn't go as planned in #NoEstimate ?

Here is my problem. From time to time, the team is hitting an unforeseen problem during implementation. As they try to solve the problem, they take longer than expected to "do the thing".

Sometimes it's OK because it must be done "what ever it takes" but ultimately it should be a PO call.

Daily update vs estimations helps there because we can "see" that a problem is happening.

#til Aujourd'hui je me suis posé la question de notre capacité de réalisation en tant qu'équipe de dev agile.

D'obédience #noestimate ce qui m'intéresse ce sont le nombre de tickets qu'on délivre, le ratio feature / bugfix / tech.

Ainsi que le *lead time* moyen par ticket, soit le temps en jours le plus effectif entre le moment où on prend la tâche et le moment où on la considère finie.

Dans mon cas, une approximation acceptable est depuis le premier commit d'une PR jusqu'à sa fusion.