Defining your unit of immutability means understanding what is the smallest unit of work definition that will not change once the work has started. A few examples:
Of course, this doesn’t mean that you can never change your mind: if you change your mind and need to revisit a decision, you simply create a new “unit of immutability” and wait for that to be implement and revert/adjust your previous work (e.g., next ticket, next sprint, next quarter).
A narrow unit of immutability (e.g., the ticket) makes the work more unpredictable and complex initiatives more difficult to implement, but also allows the org to move much faster.
A wide unit of immutability (e.g., the quarter) gives the team peace of mind, because they know what’s coming and can plan accordingly. It also allows implementing more ambitious and more elaborate plans. On the other hand, it makes the org more rigid and slower to respond to change.
The natural journey of most startups is to start with an incredibly small unit of immutability, or no unit of immutability at all (i.e., tickets are changed even when they are in progress). This is the result of having to move very quickly as the business is learning about the market and about itself, and is constantly changing direction.
As the org matures and the team acquires knowledge and inventory, it starts to gradually expand its unit of immutability, because the decisions that are made take a longer time to implement, and they can be (hopefully) made with more confidence.