Bag, Box, or Something Else?

After five newsletters on the topic of Bags & Boxes, it’s time to wrap up the series.

And what better way to do it than with a game?

Below, I’ll list examples of tools, ceremonies and artifacts that exist in any organization. Your task is to decide whether we’re talking about a Bag, a Box or… something else.

Ready to play?

User Story Format

User stories are the most intimate layer of team collaboration. They live inside the team, not outside. Forcing a company-wide format will just create useless complications.

If your PM or PO don’t know how to write user stories, train them, but don’t force templates. User stories are Bags, all the way. Got this one wrong? You owe an apology to your PO.

Initiative Format

Initiatives are handled by several teams and functions. Without a shared format, they require a much higher cognitive load - a load that has no reason to exist. By now, you must have guessed: they’re definitely Boxes.

Retrospectives

I must confess: retrospectives are one of my favorite topics!

Teams should do retros, of course. But the truth is that, if they don’t, nobody notices.

The team will likely slow down, quality will drop, and morale might fade. But unless someone is watching closely, the absence of retrospectives will go unnoticed. This is less a good practice problem, more a management o performance one.

If you said Box, I get it. But no. Bags. This one separates optimists from control freaks.

Definition of Done

This one is a tricky one and I’ll tell you upfront: it’s a Bag in a Box.

Having a definition of done? Box.

The contents of that definition? Bag.

You don’t need universal checklists, but you do need a rule that each team defines one. Maybe you reference a few shared standards (e.g. security compliance), but don’t overprescribe.

Sprint Length

Do all teams need to follow the same cadence?

In some organizations, yes. In others, it adds no value.

But this isn’t a personal choice, it’s a context-dependent decision.

So, the right answer is (PMs, you’ll like this one): It depends!

Reporting Format

Reports are written to be read by people external to the teams.

The more scattered the formats, the more brainpower wasted trying to decode them. Is this where you want to invest your company’s time and money? Probably not. Standardize it so people can focus on the content, not the format.

Daily Stand-ups

Like most Scrum team rituals, stand-ups are Bags.

The logic is the same as for the retrospective: who will notice if teams skip it? Exactly, nobody.

What matters is that communication happens. Whether that’s on a meeting, Slack, or email, it’s irrelevant.

Demos

Demos are a controversial topic (we need a few of those, right?)

In most companies, demos are Bags and should probably stay that way. Why? They’re boring as hell. They’re just giant status updates nobody wants to attend. If this is your case and you’re not planning on changing it, keep demos as Bags.

But there’s a better way to do it.

If you turn demos into moments of real cross-functional learning, alignment, and celebration, it’s worth it considering them Boxes.

Or just stop doing demos altogether and save your company’s money and your teams’ sanity…

Discovery Processes

Trying to force all teams into a single discovery process is a great way to kill actual discovery. That’s how you fall into the Discovery Trap: focusing on outputs instead of outcomes.

If you think teams don’t do enough discovery, train them - don’t box them.

Discovery processes should always be Bags.

Knowledge Sharing Format

Discovery process? Bag.

How the results are shared across the org? Box.

Again, don’t make people waste brain power on trying to find knowledge. Reserve their energy for using that knowledge.

Prioritization System

This one is a trap - to be honest, I don’t have the answer either.

In theory, every investment should be prioritizable against any other.

In practice, trying to create a single prioritization system for every team is a great way to lose your mind.

No firm answer here. Just a warning sign.

Design Systems

Design systems were Boxes long before I even came up with the term “Bags & Boxes”.

Sure, nobody notices “today” if one team doesn’t use a design system component. But eventually? Everyone feels the pain.

Regulatory, Security, Accessibility

Originally, I thought these were exceptions.

But they're not, they’re exactly what boxes are made for: rules that, if broken, will be noticed by legal, by security, by someone filing an accessibility complaint.

Regulatory, Security, Accessibility are a Box, a Box, and another Box.

Tooling

I’ll finish with a question I get asked often: “What about Jira?” [Replace Jira with whatever other tool your team uses]

Tools should be Bags. You don’t care what a team uses as long as everyone else can find the information they need, when they need it.

But let’s be real: you’re not going to pay for ten different tools that do the same thing. So at some point, tooling becomes a Box by force, not by nature. Trunks?.

That’s it for this series.

I might put all six editions into a compact ebook this summer (let me know if this is something you’d be interested in!) But for now, we’ve reached the end of the Bags and Boxes topic.

If you got all the answers right, congratulations! If not, you know where to find my previous newsletters 😄

Thanks for playing - speak soon!