Share this page!

Allen Holub Profile picture
Twitter logo
Jul 11 • 4 tweets • 2 min read
We learn as we work. Usually, that means we discover new stories as we work, and often, those are more valuable to our customer than anything on the backlog, so they go to the top. That means that stories at the bottom of the backlog will probably never be implemented. →
There's also the issue of "work in progress." Putting any effort at all into stories we won't implement is waste, and we don't know if we'll implement or not because we can't predict if something more important will come along. →
Finally, everything we release _changes_ the domain. Stories based on the old state of the domain are commonplace, and worthless. →
As an aside, if the backlog is too large, finding value in it is much too difficult.

The best solution to all these problems is a very-small backlog. Many orgs have none at all. Many limit it to the number of teams (or #teams * 2). Too-old items are always discarded. ✖️

• • •

Missing some Tweet in this thread? You can try to force a refresh
　

Keep Current with Allen Holub

Allen Holub Profile picture

Stay in touch and get notified when new unrolls are available from this author!

Read all threads

This Thread may be Removed Anytime!

PDF

Twitter may remove this content at anytime! Save it as PDF for later use!

Try unrolling a thread yourself!

how to unroll video
  1. Follow @ThreadReaderApp to mention us!

  2. From a Twitter thread mention us with a keyword "unroll"
@threadreaderapp unroll

Practice here first or read more on our help page!

More from @allenholub

Allen Holub Profile picture
Jul 8
Too many ppl seem to use Jira's breathtakingly incorrect definitions of story, epic, task—one way that using Jira distorts your process away from agility. What are they really? 1/7
A "story" is one or two sentences that describe your customer's work, not yours. They describe the domain, not a computer program. They are a place holder for a longer conversation that happens just before you implement (hours, not days). 2/7
During that conversation, you'll gather enough information to _start_ (not finish) implementing. The conversation continues as you work (and get feedback) so that you collect more details as you work. 3/7
Read 7 tweets
Allen Holub Profile picture
Jul 7
Dear @Shopify merchants: there's a new "feature" in Shopify. Your customer puts together an order. They pay for it (in my case, with Paypal). 1/3
Then, on the very last "confirmation" page, the one with the actually-buy-it button that you see _after_ payment, they're told that many of the things they thought they just purchased are out of stock. Too bad, sucker! 2/3
This is insanely annoying, to the point that I'm avoiding stores that use @Shopify. This has happened to me several times. So, dear merchant, you may want to look around for another eCommerce platform. This one is costing you at least one customer. 3/3
Read 4 tweets
Allen Holub Profile picture
Jul 4
@unclebobmartin @anitssh Bob. The problem is that µservices must be independently deployable. E.g., given that they have to be tested in production as well as dev, deploying more than one at a time is dangerous. 1/4
If they share a compile-time-linked library & you change the lib, you may have to recompile & deploy all the services that use the lib. Consequently compile-time-linked libraries are an antipattern. One solution is to make the library into a independently deployable service. 2/4
However, one big service can create SRP and ISP problems, so breaking up the library service into smaller services makes sense as well. Taken to an extreme, each library function can be implemented as a standalone AWS-Lambda. 3/4
Read 5 tweets
Allen Holub Profile picture
Jul 4
One of the problems with the SOLID principles is that they're often described in complicated ways involving language-specific code examples that are not particularly helpful. Here's the gist (my take, not Bob's): 1/4
• Single Responsibility: All the pieces of a component should focus on achieving the same goal.

• Open/Closed: You should be able to change a component's behavior w/o modifying the component. 2/4
• Liskov: As long as an interface doesn't change, the clients don't care if you change the implementation.

• Interface Segregation: Prefer small focused interfaces that adhere to SRP.

• Dependency Inversion: Depend on the more-abstract thing. 3/4
Read 4 tweets
Allen Holub Profile picture
Jul 2
Dan makes an important point, here. The SOLID principles were incredibly valuable when @unclebobmartin wrote about them, but they were solving problems of the time and we've moved on. E.g. 1/4
Open/Closed solves a problem that's very specific to OO programming and over-large over-complex implementations. Nowadays, some of us at least are writing the code to be as dead simple as possible, and that makes continuous refactoring possible. 2/4
In that environment, there's no need to add the complexity of things like the Strategy pattern, which is are the center of realizing Open/Closed. 3/4
Read 4 tweets
Allen Holub Profile picture
Jun 17
There is no such thing as a "kanban board" in the in a Lean factory. There are many boards, one associated with each workstation. 1/8
When inventory on a necessary component part runs low, the user of that part passes a card upstream to the maker of that component, who puts it onto their board to trigger its production. 2/8
Because of setup issues, there may be several boards, in fact, one for each workflow that uses that workstation. You'll activate a specific board when you're working on a specific component. 3/8
Read 8 tweets

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just two indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member ($3/month or $30/year) and get exclusive features!

Become Premium

Don't want to be a Premium member but still want to support us?

Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal

Or Donate anonymously using crypto!

Ethereum

0xfe58350B80634f60Fa6Dc149a72b4DFbc17D341E copy

Bitcoin

3ATGMxNzCUFzxpMCHL5sWSt4DVtS8UqXpi copy

Thank you for your support!

Follow Us on Twitter!

:(