General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Dave Taht <dave.taht@gmail.com>
To: bloat <bloat@lists.bufferbloat.net>,
	 cerowrt-devel <cerowrt-devel@lists.bufferbloat.net>,
	 Dave Taht via Starlink <starlink@lists.bufferbloat.net>
Subject: [Bloat] story points are pointless, measure queues
Date: Tue, 16 Jul 2024 19:19:57 -0700	[thread overview]
Message-ID: <CAA93jw5tO9qLi3yjRCy-_R5F8MmrHEJu_dOzNY1uOJCGRY4tkw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1344 bytes --]

It's nice to see queue theory enter another discipline (scrum software
development), although the article takes a very long time to get there,
first discussing the failures of "points" in the developmental process,
before introducing queue theory 101.

https://news.ycombinator.com/item?id=40969693

The "Full Queues Amplify Variability" chart is nice. Also I had not heard
of Reinertsen before, using different language for other

From the above:

"Reinertsen's books are very, very good. The most recent and most
up-to-date is Principles of Product Development Flow, which that chart came
from. The previous one, Managing the Design Factory, is pretty similar and
I think it's a better read.

Another great takeaway from it is to prioritize things by cost of delay, or
even better, what he calls Weighted Shortest Job First, where you divide
the cost of delay by the expected length of the task."

Perhaps an fq_codel like approach can be applied to complex
product development tasks? i have always been highly influenced by "Getting
Things Done", and both toke and I are huge advocates of org-mode in emacs,
not that modern computing environments make this sort of flow easy.


-- 
Artists/Musician Campout Aug 9-11
https://www.eventbrite.com/e/healing-arts-event-tickets-928910826287
Dave Täht CSO, LibreQos

[-- Attachment #2: Type: text/html, Size: 2841 bytes --]

                 reply	other threads:[~2024-07-17  2:20 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAA93jw5tO9qLi3yjRCy-_R5F8MmrHEJu_dOzNY1uOJCGRY4tkw@mail.gmail.com \
    --to=dave.taht@gmail.com \
    --cc=bloat@lists.bufferbloat.net \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=starlink@lists.bufferbloat.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox