A rebrand has no open questions, so it does not belong on a sprint board

Writing on dev.to under the title "A rebrand is not feature work," the developer Tony Rowan argues that a full-app rebrand has no open questions in it, and therefore gains nothing from being delivered in sprint-sized slices ^[1][3]. That matters because the default in most product organisations is to put every unit of work on the same board and let it compete, and Rowan's account of three employers is that the board is where rebrands go to not finish ^[18]. The argument turns on what iteration is for. Lean and agile methods exist to answer questions you do not know the answer to: ship early, ship often, learn from real users, adjust ^[2]. A rebrand does not qualify, in Rowan's framing, because scope is fixed on day one front to back, the decision has already been taken above the team doing the work, and the only remaining question is how to get there, which is an execution problem rather than a product one ^[3]. He is careful to separate this from a product or UX redesign, where the right flow genuinely is unknown and iteration is the only way to find it; agile is built for that kind ^[4]. Ship a rebrand in pieces and there is nothing to learn from watching what happens, only users being confused on a schedule set by your sprint cadence ^[5]. Rowan says he has been a developer for over a decade and has worked on five rebrands at three companies, plus marketing-only rebrands that never needed developer input ^[6]. His most recent attempt spent more than a year fitting the work around everything else, a page here and a flow there whenever a sprint had room ^[7]. The result he describes is a product that visibly looked like two apps stitched together for months, half the screens on the old brand and half on the new, with every release making the seam more obvious rather than less, until users noticed and trust eroded ^[8]. The budget is the instructive part. It was a team of three on two-week sprints with roughly 10 percent of time reserved for the rebrand, for a year, and Rowan says nearly all of it was wasted ^[9]. Ten percent of a two-week sprint is about one day per developer, so the whole reservation was on the order of three developer-days a sprint ^[11], or roughly 15 person-weeks across the year ^[12]. On at least three occasions, he says, arguing about how to handle a single piece of work cost more than that reserved 10 percent, because a component had been rebuilt elsewhere, a pattern had moved, and nobody could agree what "on-brand" meant that week ^[10]. The other two cases fail in the opposite directions. One company kept a "kaizen" board, an unprioritised pile of tasks, bugs and refactors that developers rotated onto for a week at a time; rebrand tasks were dumped there and never fully migrated in two years, with about a dozen still sitting on it when Rowan left ^[13]. At another, a four-person team pulled one developer off sprint work to build the whole rebrand behind a feature flag while the other three kept shipping features, mostly new minigames, at the usual pace ^[14]. Piecemeal release was ruled out and so was slowing feature work, so new features were built in the old style for the solo developer to convert behind the flag later ^[15]. Nothing could ship until everything shipped, the developer was eventually recalled to feature work, and the rebrand was still unreleased behind the flag at least nine months later ^[16][17]. Across the three accounts that is at least three years and nine months of rebrand work in flight and none of it landed cleanly ^[19].