This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-07-30
Channels
- # announcements (4)
- # babashka (8)
- # beginners (124)
- # calva (13)
- # cider (10)
- # circleci (6)
- # clj-kondo (193)
- # cljdoc (1)
- # cljs-dev (4)
- # clojure (50)
- # clojure-europe (28)
- # clojure-serbia (1)
- # clojure-spec (22)
- # clojure-uk (30)
- # clojurescript (11)
- # clojureverse-ops (3)
- # community-development (1)
- # conjure (5)
- # cursive (1)
- # datomic (11)
- # depstar (1)
- # events (2)
- # fulcro (7)
- # graalvm (2)
- # graphql (10)
- # helix (43)
- # hyperfiddle (14)
- # introduce-yourself (6)
- # jobs (2)
- # jobs-discuss (14)
- # kaocha (4)
- # luminus (2)
- # malli (24)
- # meander (6)
- # off-topic (4)
- # pathom (1)
- # polylith (13)
- # re-frame (6)
- # releases (1)
- # remote-jobs (1)
- # sci (14)
- # shadow-cljs (209)
- # tools-deps (30)
- # xtdb (26)
I think people need to understand that these things are called ‘estimates’ for a reason. Software development is not a manufacturing. It is hard to estimate. For ‘always missing spring’, it usually has two reasons: 1. Too much work in the sprint. A question is - can the team deliver everything if workload is half? 2. I have seen many times, that teams failed even on half workload. And the reason was interconnected tasks, 3rd party risk. In such a situation, it’s great to understand a critical path of tasks. As I am believer in Scrum’s quality (if implemented well), it is not for everyone and it is just a point in time. When it is implemented, it should be “abandoned for good” in retrospectives during which teams change it for something that works better for them. In my team, we do no estimates, Monday, Wednesday, Friday, we show our work and tell what we are going to work on next. Tasks in backlog are prioritised by Kano’s model (must be first; performance second; detractor-removals third; excitement last).
You know @dharrigan, every time I see your icon on here I assume that you look like Michael Garibaldi...
Morning.
Interesting @jiriknesl, I totally agree with your points on estimation, sprint packing, and specifically interconnected tasks. I’d not heard about Kano’s model. I’ll dig into that.
We have mixed it with walking skeleton. So every module in the app we build (recruitment system inspired by Spacemacs) gets first implemented most important features for Candidate tracking, Tasks, Team X Person matching, Learning modules are implemented, Then performance… It gives quite a lot of input on priorities and the best thing is that the team can prioritise without any Product Owner (which is my role in fact).
In practice I've learned to be political, try to understand the person in front of me and give them what they need. Often this is not actually about estimates. Sometimes people don't take anything but a single kind of answer, there I try to leave them in peace and look for others to work with. Or if I can't do that, I draw the lines.
morrrrning
yeah i tend to say whatever is most appropriate to the situation and culture at the time
but i mean, i've had simple aws jobs that could be done in the UI take two weeks when i had them figured at an hour of work, and i've had big bug tickets end up being 2 minutes (literally) of work
this job that we do is just kinda dumb sometimes, and i think it's hard to explain that to stakeholders that don't understand just how dumb this job is
i try these days to say things are either 1 day, 3 days, 1 week + or "i don't really know"
Yeah, I tend to follow something a bit like that but "1 hour, 1 day, 1 week, don't know". And I try hard to break things down into either 1 hour or 1 day for each ticket.
if it's "i don't know" and i'm a team lead i always then go really hard at making the i don't know thing die a death or be rethought until it's at least "we can break it down"
if i'm an IC then i'm more like yolo it's your money depending on whether it's a hill worth dying on tbh
Yup, to both of those. I often push back on the "don't know" with a list of "here's the minimum set of decisions you (management) need to make about this and here are initial questions I need answering" -- and that's often enough for them to say "Ah, yes, too complex/vague at this point! Maybe we'll come back with a better set of reqs later."
& i'm always wrong anyway 🤷
i literally should get something like this on a t-shirt tbh
insightful preview text from wikipedia there
Yeah, I tend to follow something a bit like that but "1 hour, 1 day, 1 week, don't know". And I try hard to break things down into either 1 hour or 1 day for each ticket.