Tuesday, 30 June 2026

We, your children, have decided to adopt the Scrum framework to handle your change requests.

 

 

 

 Submitted to McSweeney's Internet Tendency on June 24, 2026 - Rejected

_____________________________________________ 

 

Dear Mum and Dad,

We would like to inform you that, from now on, we will handle all your requests using the Scrum framework. Although Scrum originated in software development, it has also been adopted in other areas where complex work is carried out. This framework has proven very helpful in creating transparency for the customers (i.e. you) and helping the Scrum team (i.e. us) to improve relentlessly in order to maximise value.

 

Scrum is an iterative approach, with iterations typically lasting two weeks. However, since shorter iterations are preferable to longer ones, ours can range from “between now and bedtime” to “I’ll do it later” (which usually translates to “never”, as in software development). 


You can always suggest new items, which the Product Owner (our eldest sister) will then carefully analyse, before the team refines and estimates them and finally inserts them into the prioritised backlog. Scrum teams usually use a tool called Jira to create new tickets, but in our case, it is sufficient to send a quick note in the family WhatsApp group chat. Please note that shouting requests towards our closed doors is no longer an acceptable approach.


A key member of the Scrum team is the Scrum Master, who is responsible for all ceremonies (meetings, here: meals), artifacts (outcomes, here: drawings for Grandma’s birthday) and information radiators (Jira boards, here: Post-its on the fridge) and ensures that the rules of the Scrum framework are followed. The Scrum Master also helps people outside the Scrum team to understand which of their interactions with the team are helpful and which aren’t. In practice, this means telling people to leave the team alone. In our case, the Scrum Master role will be filled by Luna the Labrador.


Let’s go back to the finer points of Scrum mechanics. Imagine the customer introduces a new and important item such as: “Pick up all your clothes from the floor, but don’t just throw them on the bed!” This will automatically receive a severity rating of “high” in our ticketing system, where “high” is the lowest severity category, followed by “higher”, “very high”, “super high”, and the most severe category: “non-compliance might result in reduction of screen time”.


Although this new item may seem random and offer no apparent value to the customer, it is considered very important. The Scrum team trusts the outcome of the preliminary triage process and includes this request in the list for the next refinement, in accordance with the SLAs between the Scrum team and the customer (who are also a “team” of sorts, albeit with inconsistent priorities).


The new, fast-tracked change request then needs to be refined. This process ensures everyone has a clear understanding of the item. The Product Owner usually answers the team’s questions such as “Why?” They also note acceptance criteria like “the floor is devoid of items” and “the bed is not filled with the aforementioned items”.


Then, the item will be estimated using arbitrary and meaningless units, such as “number of groans and tantrums to be thrown while doing it” or “amount of false starts due to distractions caused by things that suddenly became very interesting”. When the description of the change is “ready” (we define what this means) or when the customer raises their voice, it will be added to the “repository of things that are not so far away as the items in the actual backlog but also nowhere near the next iteration”. (We call this the “Limbo of Liabilities”, or LOL for short.) 


Sticking to the framework ensures that the team only works on the most important items, but Scrum is “agile” and embraces change. For example, an even more important item could suddenly appear, such as “ice cream”. A Scrum team has a fixed velocity or “amount of stuff they can do before they start complaining/crying” and when something new is added to the list, something else has to be removed. In this case the team would have an ad hoc discussion about it, which might very well lead to the new item replacing some of the items that were already planned for this iteration, like “doing homework” or “cleaning the dishes”.


After each iteration, the Scrum team demos their progress to the customer and gathers feedback. A customer representative checks if there is really nothing left on the floor (or bed). In this situation, customers will often make additional requests, which they claim were also implied in their initial request. This is called “scope-creep”. For example, they might ask “Why are there still five empty bubble tea cups on the couch?” A common mistake made by Scrum teams is to implement all the feedback immediately. Experienced Scrum teams however ask their Product Owner to gather all the feedback in the backlog and re-prioritise it. Sometimes Luna will then eat the backlog. 


It is also important to avoid customisation and instead implement standard solutions for all customers. Some items benefit all customers (i.e. Mom AND Dad), whereas others serve just one of them. “Could you give ME a hand with MY [insert random chore]?” is a dead giveaway that the customer would like the Scrum team to focus on their individual needs, which does not benefit us as a group in the long term. Items that are more generally applicable (“I guess WE will have to upgrade to a YouTube Premium FAMILY account.”) should be prioritised.


Finally, the Scrum team comes together for a Retrospective meeting, where they review how they worked together and devise action items to improve. This is usually an intimate setting, free from corporate overhead. The Scrum Master has to create a trusting and respectful environment in which the Scrum team can be open and discuss problems. The so-called “Vegas-rule” is displayed prominently and followed, albeit adjusted to the specific environment: “Whatever happens in the tree house, stays in the tree house”. (Unless junior members of staff start crying again because a senior member of the Scrum team has eaten all their chocolates, in which case this must be escalated immediately to the C-Suite.)