@stephane_jans I have nothing but stories on my (very small) backlog. User stories describe your user's work, not yours. They are literally the User's story. Stories describe problems, not solutions.
@fauxcode Did you read the whole thread? Bugs are _never_ user stories. User stories describe the user working in the domain. They describe domain problems and issues. They describe your customer's work, not yours. If a bug doesn't stop work in the domain, ignore it.
The biggest bottleneck in software development is lack of skills needed to vertically slice user stories. It is useless, nay harmful, to strive to increase collaboration if the user stories are not vertically sliced. Horizontally sliced stories always lead to hardening of silos.
@RyanTomczik I suggest working on _user_ stories, not tech tasks. Organize your work around the user stories. Implement the story end-to-end, doing whatever tech you _need_ to do to pull that off.
Backlogs are a symptom, not a tool. The very existence of a backlog tells you that you don't have the capacity to do the work, so you defer it. Replace the backlog w/ capacity. Improve processes. Don't work on non-value-add stuff. Minimize waste. Hire ppl. Do whatever it takes.
Przypomniała mi się właśnie pewna scena, która na dobre została w mojej pamięci z covidiańskiej epoki.
Nigdy tego nie zapomnę tym *rwiesynom z pod znaku @pisorgpl 👆
Hackatons in corporations: after years of crazy deadlines, boring tasks, and suppressed ideas, we expect our developers to suddenly become creative on a certain date and build something really innovative.
Hint: scheduled innovation doesn't work. Because creativity is spontaneous, innovation only happens when developers are allowed to experiment and try out new things every day, when they "catch the wave".