Making technology teams work better
Making technology teams work better
The velocity chart is full. The sprint review produces a demo. The backlog has items stretching months into the future, and every sprint the team completes the stories it planned. None of this is the same as delivering business value, and the distinction is one most organisations are not measuring.
There is a version of Scrum that looks, from most angles, like it is working. The team completes the sprint. Velocity is stable, sometimes rising. The sprint review has something to show. The product owner accepts the stories. Planning runs to time. The board empties reliably at the end of every sprint.
What the board does not show is whether any of it mattered. Velocity tells you how fast the team is moving. It does not tell you where they are going, whether the destination was worth reaching, or whether there was a better destination available. A team can hit every sprint goal for twelve consecutive sprints and still deliver nothing of material business consequence. The ceremonies do not prevent this. In the absence of genuine value-based prioritisation, they actively conceal it.
This is the second failure mode in the Performative Scrum Syndrome series. The first article examined what happens when the Self-Organisation principle is absent: the team goes through the ceremonial motions without the structural conditions that would allow those ceremonies to produce real coordination. This article examines the fourth principle, Value-Based Prioritisation, and what happens when the team is doing the right ceremonies with the wrong compass.
Completing stories is not the same as delivering value. Most teams know this. Most organisations are not measuring the difference.
The six Scrum principles that underpin the framework are introduced in the first article in this series, which also sets out the structural conditions each one presupposes. Value-Based Prioritisation is the fourth. It is worth being precise about what it actually demands, because it demands considerably more than most product backlogs reflect.
This principle presupposes three things that must actually be true: that value is defined, that someone has the authority to act on that definition, and that the backlog genuinely reflects it rather than a pre-agreed sequence of work that nobody has revisited since it was written.
The mechanism Scrum uses for this is the iterative cycle: rather than defining the full product upfront, the team builds a small increment, puts it in front of real users or stakeholders, observes what it learns, and uses that learning to adapt what comes next. Each sprint runs through four stages: a hypothesis (the product owner’s current best view of what the team should build and why), execution (the sprint itself), inspection (the sprint review, where the real increment is tested against reality rather than a mockup), and adaptation (the backlog changes to reflect what was learned). The three pillars that make this possible are transparency (all parties are working from the same shared understanding of the product and the market), inspection, and adaptation. If the backlog does not change in response to what the sprint review reveals, the adaptation has not happened. The cycle is present in name and absent in function.
Read carefully, this principle is demanding. It requires that the product owner can answer, at any point, the question: “If we could only ship one thing from this backlog this sprint, what would it be, and why?” It requires that the answer changes as circumstances change. It requires that the backlog is a living prioritisation of outcomes rather than a fixed decomposition of a pre-approved plan. And it requires that the product owner has the authority to act on their own answer without taking it to a committee.
In the organisations where this principle is genuinely operating, the backlog shrinks before it grows. Items are regularly pruned when they are no longer the highest-value option. Sprint goals are expressed in terms of outcomes rather than story counts. The product owner can, and regularly does, reprioritise between sprints in response to what the previous sprint revealed. The team knows why the next sprint matters, not just what it contains.
In the organisations where it is not, the backlog is a sequenced requirements document, the sprint goal is a caption added at the end of planning, and velocity is the metric everyone watches because it is the only thing being measured.
The failure of Value-Based Prioritisation is not usually sudden or dramatic. It accumulates across many sprints, and because the team is completing work throughout, it rarely triggers an alarm. These are the three patterns that signal it most clearly.
The sprint goal is Scrum’s mechanism for anchoring the team’s sprint cadence to an outcome that matters. Done well, it describes what should be true at the end of the sprint that was not true at the beginning: a customer can now complete a specific journey, a specific risk has been retired, a specific decision can now be made. Done poorly, it describes what will be built: a list of stories or tasks, a number of points, or a feature that has been in the plan since the project was scoped.
The Engineering Manager decided how long the team would get to work on each feature and set the deadline. The feature lead took that deadline, built a week-by-week plan detailing who would work on which items and for how many days, and updated it each week to reflect progress and slippage. The plan existed before sprint planning. Sprint planning was the meeting at which the feature lead briefed the rest of the team on the work required, often the first time the team had seen it. The sprint goal, on the occasions one was written, described the tasks just assigned. It could have been written before the meeting started.
The sprint review followed the same logic. The team showed what had been built. Progress was assessed against the feature deadline, not against a business outcome. Nobody asked whether the work completed in this sprint was the most valuable use of the team’s capacity, or whether the product was moving in the right direction. The deadline was the measure. The deadline had been set by management before the team had seen the work.
The diagnostic signal is in the sprint goal itself. When a sprint goal could have been written before planning started, based purely on where the team was in the sequence of work, the planning event is not a prioritisation exercise. It is a scheduling one. The team is not deciding what matters most. They are deciding how to fit this period’s predetermined items into a sprint.
The question that exposes the difference is simple: “Could the sprint goal have been different?” In a team operating genuine value-based prioritisation, the answer is sometimes yes, because the team has compared options and made a choice. In a team running on sequence, the answer is almost always no, because there was nothing to compare. The backlog tells you what comes next. Value is not the organising principle. Order is.
Every backlog is, in some sense, a set of things to do. The question is what determined the order. In a genuinely value-prioritised backlog, the ordering reflects a view about business impact: which items will generate the most return, retire the most risk, or unlock the most learning. In a sequenced backlog, the ordering reflects technical dependency and delivery logic. The items higher on the list are there because the items below them cannot be started until the ones above are complete.
The roadmap was organised as a series of features to be delivered, each with its own product manager and a deadline set by the Engineering Manager. A designer worked the feature up into a solution ahead of development. When development time approached, the feature lead in the engineering team decomposed the design into tasks, identified what could fit within the time allotted, and briefed the team. Work that did not fit the deadline was parked. Parked work then competed against new features for a future slot and most of it never returned.
Nobody asked which half of the roadmap was most valuable. The roadmap was the commitment. Questioning it would have meant questioning decisions made above the team’s authority level. The backlog that resulted was not a prioritisation of outcomes; it was a decomposition of a predetermined delivery sequence, with each item’s position determined by its feature’s deadline rather than its business value. The team’s job was to execute the sequence. The question of whether the sequence represented the most valuable use of their capacity had been answered, implicitly, when the roadmap was approved.
Sprints are not only a mechanism for delivering work. They are also a mechanism for learning: whether what was built is what was needed, whether the hypothesis behind the backlog item held up when something real was in front of a real user, and whether the next sprint should confirm the direction or change it. A backlog ordered by technical dependency cannot accommodate that learning. There is no slot for “we built it and discovered the assumption was wrong.” The plan continues regardless of what the sprint revealed.
The most revealing test for a backlog is not its length or its detail. It is whether it has ever been pruned. A backlog that has never had items removed, superseded, or explicitly deprioritised is not a prioritisation tool. It is an accumulation of commitments made at various points in the past, ordered by the logic that governed those commitments, none of which is being revisited in light of what has been learned since.
Scrum’s inspection and adaptation loop presupposes that the team learns from each sprint and that what they learn changes what comes next. The learning happens in two places. The retrospective examines how the team worked: process, communication, and the structural friction that got in the way. The sprint review examines what was built and whether it moved the product in the direction it needed to go: whether the increment advanced the outcome it was built for, and what that reveals about what should come next. Both matter, but they answer different questions. A team that runs thorough retrospectives and never asks whether the sprint advanced the right outcome is improving its way of working while leaving the direction unexamined.
If the backlog does not change in response to what the sprint review reveals, the loop is broken. The team is adapting its process in the retrospective and then reverting to the pre-existing plan in planning. The inspect step produces no adaptation of the backlog direction. The adaptation is aesthetic.
The product owner is the structural linchpin of Value-Based Prioritisation. The principle requires a single person with the authority to say what the team will build and the business knowledge to ground that decision in genuine impact. When that authority is absent or distributed, the backlog defaults to sequence rather than value, because sequence is the only basis for ordering that does not require anyone to take a position.
The person holding the product owner title creates tickets and assigns them to engineers. The tickets describe tasks, not outcomes. Scope decisions, priority calls, and any change to the plan are made by a senior stakeholder group that meets periodically, whose decisions filter down through the product owner as instructions. The product owner has no authority to accept or reject scope, no mandate to make trade-off decisions, and no ownership of the product outcome.
Their actual job is to keep the board current, ensure tasks are assigned, and report progress upward. The role is, in function if not in title, a traditional project manager: maintaining a plan that someone else authored, tracking execution of work that someone else defined, chasing completions against a schedule that someone else set. Sprint planning in this context is not planning. It is task assignment. The sprint goal, where one exists at all, is written at the end of planning rather than the beginning: a sentence constructed to describe the tasks that have just been assigned, working backwards from the list to find a label for it. It is not a goal that shaped the work. It is a caption for work that was already decided.
When a stakeholder asks why the team is working on the current sprint content, the product owner can explain what the team is doing and when each feature is due to land. They cannot explain why this sprint’s work represents the highest-value use of the team’s capacity relative to the alternatives. That question has not been asked. The plan is the answer. The plan was decided before the team started work, and it has not been revisited in light of what the team has since learned.
The team had a product backlog and a sprint plan. They also had a manager who held authority over defect prioritisation as a separate function from the team’s normal planning process. When a bug surfaced that the manager considered high priority, it was handed to the team directly: stop what you are doing, fix this first. The sprint plan was not updated. The sprint goal was not revisited. The work simply appeared, and other work was quietly displaced to accommodate it.
This happened often enough that the team had developed an informal norm around it. They left slack in their sprint commitments to absorb the interruptions they knew were coming. The sprint goal was written loosely so that it would still be achievable after an unplanned bug fix had taken two days out of the middle of the sprint. The backlog prioritisation work the product owner did before planning was real work, but it was only partially in control of what the team actually worked on. The other part was controlled by whoever shouted loudest between sprint reviews.
The product owner could not push back on these interruptions because the authority that would have allowed them to do so sat with the same manager who was sending them. The backlog reflected one priority order. The sprint reflected another. The gap between the two was the measure of how much the principle was actually operating.
The product owner without authority is a symptom, not the cause. The root condition is a governance model that treats the product backlog as a project plan rather than a living prioritisation instrument. In a project plan, the work is committed at the start. Deviations require change control. The team’s job is to execute. In a genuine product backlog, the next sprint’s content is always a fresh decision, even if it usually confirms what was expected, because the team has inspected what they learned and confirmed that the plan still reflects the highest-value option.
The difference matters. In the first model, the product owner is a project manager by another name. In the second, they are a continuous decision-maker whose job is to ensure that each sprint the team works on the most valuable thing available. Those are different roles, and most organisations have not clearly decided which one they need.
The experience of working inside these patterns is recognisable to anyone who has lived it. The product owner who has spent two days preparing a carefully reasoned backlog prioritisation for planning, and watches it overridden in the first ten minutes by a stakeholder who has not read it. The engineer who writes a loosely worded sprint goal on purpose, because they already know what is coming mid-sprint and a tight goal would only make the interruption harder to explain, making the team look like they had failed to deliver: not because they had not worked, but because the plan they were being held to was never fully in their control. The team that produces a polished sprint review demo, and fields a roomful of nods, knowing that the demo bore no relationship to what the business most needed and that nobody in the room asked the question that would have exposed it. The work gets done. The ceremonies run. And the gap between what the team is building and what would actually matter widens, one sprint at a time, invisibly.
The product owner without authority over the backlog is not a product owner. They are a plan custodian. Scrum gives the product owner a role; governance gives them a job. When the two conflict, governance wins, and the principle disappears.
Velocity is a useful number when it is used correctly. Its legitimate purpose is forward projection: knowing how much work a team can sustainably complete in a sprint provides the basis for forecasting when a given body of work is likely to be done. A runner calculating a marathon finish time from ten kilometres of pace data has a useful estimate, not a commitment. Sprint velocity works the same way; it shapes decisions about what is realistic, what needs adjustment, and what trade-offs have to be made. That usefulness depends on two conditions: the baseline must be recalibrated frequently as team composition, workload mix, and complexity shift, and projections must be treated as estimates to be revised rather than commitments to be defended. A velocity measured at sprint 4 is not a reliable forecast for sprint 24.
In the absence of genuine value-based prioritisation, velocity becomes the primary success metric by default. It is visible, trackable, and goes up over time as teams become more familiar with each other and their codebase. Rising velocity looks like improvement. It feels like improvement. And it occasionally is improvement, but it is not evidence of value delivered: it is evidence of work completed.
The specific cost of velocity optimisation is most visible at the story selection stage. When velocity is the metric everyone watches, the team has an implicit incentive to select stories that are well-understood, clearly specified, and technically straightforward, because those are the stories most likely to be completed and accepted within the sprint. Stories with higher technical risk, external dependencies, or ambiguous acceptance criteria get pushed down the list, or broken into smaller pieces, or carried over repeatedly until the team finds a sprint with enough headroom.
The stories that carry most business value are frequently in the second category. They are the ones that require a conversation with a real stakeholder, a decision about a trade-off that has not yet been made, or a piece of infrastructure that is genuinely hard. Velocity optimisation does not select against value deliberately. It selects against complexity; or, if the team is measuring throughput by counting completed items rather than story points, against anything that takes long or runs uncertain. Value and complexity are not the same thing, but they are correlated enough that optimising for velocity, however it is measured, systematically disadvantages the work that most needs doing.
The team calculated their velocity by totalling the hours of productive work available in a sprint: meeting time subtracted, leave accounted for, a working day’s worth of buffer removed. Everything on the backlog was estimated in hours. Planning consisted of filling the available hours up to the target number the team had been set. When the bucket was full, planning was done.
What nobody checked was whether the work selected in previous sprints had actually been completed. The question was not on the agenda, because the goal was not to finish the sprint’s work. The goal was to fill the sprint. Completion was an outcome that happened sometimes; the obligation that was tracked and reported was whether the team had accepted enough hours of work at the start. A sprint that accepted 62 hours of work against a target of 60 was a successful planning event, regardless of what the team had actually delivered by the end of it.
This is velocity used as a capacity allocation tool rather than a projection instrument. The number answers the wrong question entirely. “How much work should we commit to?” is a scheduling question. “How much work have we been completing, and what does that tell us about what we are likely to complete next?” is a forecasting one. The team was doing the first and calling it the second. The sprint target was treated as a known quantity to be filled, not a historical signal to be interpreted. Nothing about the number pointed toward a goal. It pointed toward a full calendar.
What the board does not measure An organisation running four Scrum teams at 34 points per sprint is completing approximately 544 story points per month. The dashboard shows this clearly. What it does not show is how many of those points were the highest-value items available at the time of planning, how many were selected because they were well-understood rather than because they were important, and what the cost of never asking this question has been across the year. A team working towards a clearly defined, measurable outcome: an OKR that names the business result it is trying to move, for example, has a measure that makes these questions answerable. Without it, the board is the only instrument, and the board measures completion, not consequence.
The cumulative cost of this pattern is difficult to see sprint by sprint and obvious over a longer time horizon. Six months into a programme, the team has a strong velocity record and a backlog that has never been challenged. The items they have built are the items that were planned. The items they have not built are the items that were awkward. When the business finally asks for the thing it most needed, the answer is that it is in the backlog, scheduled for a later quarter, and has been since the project was scoped. The team was working. Nobody would say they were not. The question is whether the work they completed was worth more than the work they avoided.
The instinct, when velocity is clearly being used as a proxy for value, is to improve the ceremonies. Run better planning sessions. Write clearer sprint goals. Do more thorough refinement, so the work is better understood before planning begins. The instinct is understandable and it does not work, because the ceremonies are coordination tools. They have no authority over the structure surrounding the team. They can surface the problem, but they cannot resolve it. More thorough refinement is simply more planning further upstream. It produces better-specified stories for a backlog that still has not been prioritised by value. The input to planning is more detailed. The basis on which it was ordered is unchanged.
Sprint planning cannot produce genuine value-based prioritisation when the product owner does not have the authority to reprioritise the backlog in response to what the previous sprint revealed. The planning conversation will reflect whatever order the backlog is already in, because that order was determined by forces outside the room. Improving the facilitation of planning does not change the inputs. The inputs come from the governance model.
The sprint review cannot become a meaningful progress inspection when there is no measurable outcome against which to inspect. If the team has been handed a feature list rather than a goal, the review has nothing to inspect beyond whether the features were built. The stakeholders in the room can only evaluate conformance to the plan, because there is no other frame. Running a more structured sprint review, inviting more senior stakeholders, presenting more polished demos: none of these change the fact that the review is anchored to deliverables rather than outcomes. The anchor is structural, not ceremonial.
The engineers presented their sprint work by walking through the code they had written. Pull requests, architecture diagrams, component structures. The work was real, the craft was genuine, and the engineers were rightly proud of it. The stakeholders in the room nodded appreciatively. They understood nothing of what they had seen.
Leadership left the review more anxious than when they arrived. They had sat through thirty minutes of technical output and could not answer the question their board would ask them: is the product moving in the right direction? The product owner, aware that leadership was losing confidence, worked to reassure them that everything was on track. The reassurance was sincere and entirely unsupported by evidence, because no evidence had been presented. The review had demonstrated that code had been written. It had not demonstrated that the code was advancing an outcome anyone had defined.
The pressure landed on the product owner. They became the person responsible for translating technical output into stakeholder confidence, in the absence of any shared frame for what progress looked like. The sprint review had not failed because it was run poorly. It had failed because it was anchored to the wrong thing. A review anchored to deliverables produces a demo. A review anchored to an outcome produces a conversation. The room had no outcome to anchor to.
The retrospective cannot address the direction of the backlog when its scope is limited to how the team worked. A retrospective that produces consistently excellent process improvements, sprint after sprint, while the team continues building against a sequenced delivery plan that nobody has challenged, is improving the team’s execution of work whose direction has never been tested. The team does not know whether the work is right or wrong. Nobody has stopped to ask whether anything has changed since the backlog was built, whether the assumptions behind it still hold, or whether the business problem the plan was designed to solve is still the most important one. The retrospective has no mandate to ask whether the sprint goal was the right goal. That question belongs to the sprint review and, before it, to the product owner’s authority over the backlog. In environments where the plan is treated as fixed, neither the retrospective nor the review tends to ask it at all. The assumption is that the plan is the plan, and the job of every ceremony is to serve the plan rather than to challenge it.
When value-based prioritisation is visibly absent, two responses are instinctively reached for. The first is to tighten the process: add more governance to the planning ceremony, require the product owner to present a written rationale for backlog order, introduce a formal value-scoring framework. The second is to conclude that Scrum is not working for this organisation and to look for an alternative. Both responses locate the problem in the wrong place. The ceremonies are not the variable. The structural conditions within which the ceremonies operate are the variable. An organisation that installs a value-scoring framework on top of a governance model that fixes scope at the point of approval has not addressed the condition. It has added a layer of documentation to a process that remains unchanged beneath it.
The team had introduced a pre-planning session the week before sprint planning. The purpose was to ensure that stories were well-understood before planning began, so that planning itself could run smoothly and the team could commit with confidence. The pre-planning session covered story detail, acceptance criteria, dependencies, and size. It was run diligently. Planning was better for it.
What the pre-planning session did not cover was whether the stories at the top of the backlog were the most valuable things the team could work on next. That question was not on the pre-planning agenda. The agenda was to prepare the stories for the sprint, not to evaluate whether those stories deserved to be in the sprint at all. The backlog order was treated as given. The pre-planning session was a refinement of the execution, not of the prioritisation.
Planning ran on time. Estimates were accurate. Commitment was confident. The team were working on a well-prepared sequenced delivery plan whose value assumptions had not been revisited since it was written. The ceremonies were excellent. The structural condition was unchanged.
The structural conditions described in this article persist because they are sustained by a belief that is rarely stated explicitly but is present in almost every organisation running this pattern. The belief is that completing committed work is the same as delivering value. That a team which ships everything it planned is a high-performing team. That the backlog, once approved, represents the right sequence of investments, and that the job of delivery is to execute that sequence rather than to challenge it.
This belief is not irrational. It is the product of a governance model that rewards execution and treats deviation as failure. The product owner who regularly reprioritises the backlog in response to what the sprint review reveals looks, inside this model, like a product owner who cannot hold a plan. The team that deprioritises a committed feature because the previous sprint revealed a more valuable option, or that wants to remain with a feature longer because early user feedback is showing the improvement needed to move the metric before it is worth moving on, looks like a team that does not deliver. The instinctive response of leadership is to tighten the process, not to question the belief. The belief goes unexamined because the consequences of the belief are invisible. The velocity chart rises. The board empties. The sprint review produces a demo. The cost is carried in what was never built, which is not on any dashboard.
A building contractor who completes every room on the blueprint on time and on budget has done their job. Their job is not to ask whether the building is the right building. A product team that completes every story in every sprint has done something different: they have executed a sequence of decisions that someone else made, probably months ago, in conditions that have since changed. Their job, under Scrum, is to do something the contractor’s job never was: to continuously interrogate whether the plan still represents the most valuable use of the team’s capacity, and to surface evidence when it does not.
The belief-layer diagnostic for this pattern draws on the same framework introduced in the first article in this series. The relevant dimension here is Collective Outcome: whether the team understands and holds accountability for the outcome the sprint is intended to advance, rather than the individual tasks that make up its content. A team that scores low on Collective Outcome is not a team that lacks commitment. It is a team that has never been given an outcome to commit to. The sprint goal was a story list. The review was a demo. The outcome was implicit, assumed, and never measured.
Velocity rising is not the same as value delivered. Most organisations have built a reporting structure that cannot tell the difference, and a governance model that has no incentive to ask.
Value-Based Prioritisation fails in organisations not because people do not understand the principle but because the structural conditions required to apply it are genuinely hard to maintain. There are three distinct pressures that erode it consistently.
The first is the commitment pressure of a sanctioned project. When a piece of work has been approved by a leadership team or a board, it carries an implicit expectation that the scope approved is the scope delivered. Reprioritising mid-programme is read as deviation from the plan, and deviation requires justification. In most organisations, the effort required to justify a reprioritisation is higher than the effort required to continue with the existing plan. The rational response is to continue. The backlog reflects this: the approved scope is the committed scope, and the product owner’s job is to manage the delivery of that scope, not to challenge whether it remains the most valuable option.
The second is the absence of a shared definition of value. Velocity is easy to measure: whether a team uses story points or simply counts how many roughly-equivalent items it completes each sprint, the number is visible, consistent, and improvable. Business value is difficult to measure because the organisation has not agreed what it means. Revenue impact, customer retention, risk retirement, internal efficiency, strategic optionality: these are all legitimate forms of value, they are not commensurable, and choosing between them requires making strategic trade-offs that most teams are not empowered to make. In the absence of a shared definition, the team defaults to the most legible measure available. That measure is velocity.
The third is the proxy product owner problem. As established above, many product owners hold the title without the authority it requires. When the product owner cannot make scope decisions above a certain threshold, they cannot reprioritise the backlog in response to new learning, because any significant change requires approval from a governance body that does not meet frequently enough to keep pace with sprint cadence. The backlog freezes between steering group meetings. The sprint contents are adjusted at the margins. The principle operates at the level of individual stories, not at the level of outcomes.
Governance exists for legitimate reasons. Capital allocation, risk management, stakeholder accountability: these are real organisational needs, and the processes that serve them are not optional for most technology organisations of any scale. The tension is not between governance and no governance. It is between governance designed for project delivery and governance designed for adaptive product development. The former fixes scope at the point of approval and measures conformance to that scope. The latter fixes goals and measures whether the team is finding the most valuable path to those goals. Most organisations are running Scrum on top of project governance, and the mismatch is where Value-Based Prioritisation disappears.
The structural reset for Value-Based Prioritisation requires intervention at three points: how value is defined, who has authority to act on that definition, and how the backlog is used as a decision-making instrument rather than a delivery register.
The first intervention is the most uncomfortable, because it requires the organisation to answer a question it has usually avoided: what does value mean here, specifically, for this product, in this quarter? Revenue impact, customer retention, risk retirement, technical debt reduction, regulatory compliance, and generating the product understanding that only comes from putting something real in front of a real user: these are all legitimate answers. They are not equally applicable at all times. Before the backlog can be genuinely prioritised by value, the people with authority over the product must agree, explicitly, what the current hierarchy of value is.
This is not a permanent decision. It changes as circumstances change, which is exactly the point. A team that knows its value hierarchy can look at two competing backlog items and choose between them on principled grounds. A team that does not know it is selecting by sequence, by vocal stakeholder pressure, or by technical convenience: none of which is a proxy for value.
Vocal stakeholder pressure takes recognisable forms. The HiPPo (Highest Paid Person’s Opinion) drives priority by seniority rather than evidence. The ZEbRA (Zero Evidence But Really Arrogant) argues with conviction but no data. The Seagull swoops in from outside the team, makes noise, drops a requirement, and leaves. The WoLF (Working On Latest Fire) pulls the team towards whatever is most urgent rather than most important. The RHiNO (Really Here In Name Only) holds a decision-making role but is never available to make decisions. Naming these patterns is not sufficient, but it is a starting point: the product owner who can recognise which archetype is applying pressure, and can locate that pressure against the agreed value hierarchy, has a principled basis for pushing back.
The product owner is responsible for maintaining the value definition and for communicating it to the team. The organisation is responsible for giving the product owner access to the business information and stakeholder relationships they need to form and update it. A product owner without access to customers, commercial data, or strategic context cannot define value for the team. Neither can one who has no mandate to recognise technical debt reduction or platform investment as legitimate forms of value: work that delivers no user-facing feature but reduces the cost and risk of everything that comes after it. When those categories are invisible to the value definition, the backlog systematically under-invests in them regardless of what the team knows about where the real risk sits.
The second intervention addresses the authority gap. The product owner must be able to reprioritise the backlog between sprints without requiring approval, to remove items that no longer represent the highest-value option, and to reject scope additions that would displace more valuable work. If the governance model does not permit this, the principle cannot operate, and no amount of better backlog tooling, more structured refinement, or more frequent steering group meetings will close the gap.
This is not about removing the business’s ability to set direction. A measurable goal handed to a product owner and team is entirely legitimate, and frequently it is essential. “Reduce checkout abandonment by 15% this quarter” is a meaningful objective. The team that can choose how to pursue it, surface evidence when the current approach is not moving the metric, and propose a change of approach without triggering a change control process is operating genuine value-based prioritisation even within a directed model. Autonomy in how, within a goal set by the business, is the functional condition. Goals should be measurable so that the team can recognise when the goal has been reached, or honestly acknowledge when further effort is not moving it.
The problem is not governance or direction. It is the combination of a fixed feature list with no measurable outcome and no authority to question the list. When the organisation hands the team a predetermined scope rather than a goal, requires approval for any deviation, and has no shared definition of what success looks like, the product owner cannot apply value judgement at any level. The ceremonies run, the role carries the right title, but without a measurable outcome to navigate toward and the authority to choose the route, the team is executing a plan, not pursuing a goal.
Where full authority cannot be granted, the most useful partial intervention is to agree, with the governance body, a range within which the product owner can act unilaterally. Above that range, approval is required. Below it, the product owner decides. The range should be wide enough that the product owner can respond to what the team learns in a sprint without waiting for the next steering group meeting. If the range is too narrow to accommodate that, it is effectively zero, and the product owner is a plan custodian regardless of the title.
The third intervention is behavioural as much as structural. The backlog needs to function as a live prioritisation instrument: the current best answer to the question “what should the team work on next, and why?” That requires two practices that most organisations do not sustain.
The first is regular pruning. Items that are no longer the highest-value option should be removed or explicitly deprioritised rather than left on the list indefinitely. Removed items do not have to be permanently discarded; a parking lot, a ‘Later’ column in a Now/Next/Later framework, or a separate ideas backlog gives the team a place to put things that are not currently the highest-value option without losing them entirely. The discipline is in keeping these categorically separate from the working backlog, and in being honest that items parked there may never return. A backlog that only grows is not being prioritised; it is being extended. The total count of backlog items is not a health indicator. The team’s confidence that the top of the backlog represents genuine organisational priorities is.
The second is writing sprint goals as outcomes rather than story or task lists. The sprint goal should describe what will be true at the end of the sprint that is not true now: a customer can complete a journey they could not before, a specific decision can be made with confidence it could not be before, a particular risk has been retired. When the sprint goal is written as an outcome, the planning conversation becomes a genuine prioritisation exercise: which stories contribute to the goal or advance what the team most needs to learn, and which are convenient additions that happen to fit the sprint? When it is written as a story or task list, the goal is identical to the sprint content, and the question of whether the content represents the highest-value option is never asked.
Setting a sprint goal before planning begins is not only acceptable: it is the intended sequence. The product owner, informed by what the previous sprint review and retrospective revealed, proposes a goal to planning. That goal sets the direction. The team’s job is then to assess whether it is achievable within the sprint, which stories will advance it, and, if the goal as stated is not achievable, to propose what goal they can commit to instead. The goal shapes the planning conversation. The team validates or adjusts it.
The sprint goal assembled at the end of planning, constructed backwards from the tasks already assigned, is not a goal. It is a caption. The planning that produces it had already made all the decisions before the prioritisation conversation could begin. The backlog order was the agenda. Planning was the endorsement.
The most immediate change when value-based prioritisation is genuinely operating is visible in the sprint review. The Sprint Review is not supposed to be a showcase of completed work. It is a progress inspection against a goal broader than the sprint content: an examination of whether the product increment moves the business or customer outcome it was built for, what they have learned from building and seeing it, and what should come next. That distinction changes what gets discussed in the room. A showcase ends when the demo ends. A progress inspection opens a conversation about direction.
This is a more demanding conversation. It requires the stakeholders to have a view, not just to approve. It requires the product owner to have built the case for why this sprint’s content was the highest-value option. It requires the team to understand the goal they were building toward, not just the stories they were completing or the tasks they were marking as done. Most organisations find this harder than the demo review. It is also considerably more useful.
The second change is in the retrospective. When the sprint goal is an outcome, the retrospective has a clear question to anchor on: did the team achieve the outcome, and what affected whether they did? When the sprint goal is a story or task list, the retrospective defaults to process questions, because outcomes are not in scope. Process questions produce process answers, and the structural conditions that prevented value from being prioritised remain untouched.
Over a longer horizon, the backlog stabilises at a size the team can execute. Items that are not genuinely prioritised are removed rather than carried forward indefinitely. The team’s capacity is not diluted across a list of commitments accumulated from quarterly planning sessions twelve months ago. The work the team does in any given sprint is the work someone who can see what is most valuable decided was worth doing next, and who had the standing for that decision to stick. That is a meaningfully different condition to the one most teams are actually operating under.
The velocity chart does not necessarily improve. Some teams find it drops initially, as the discipline of genuine value prioritisation surfaces work that is harder and less well-specified than the items that were previously selected for completion rate. That is not a failure. It is the metric revealing its own prior distortion: when velocity is the primary success measure, a team unconsciously selects the work that makes velocity look good: the well-specified stories, the clear acceptance criteria, the technically predictable tasks. When that selection pressure is removed and the team takes on the work that genuinely matters, velocity measures something real for the first time. The drop in the number is the rise in the honesty of it.
What opens up, once these conditions are in place, is something that cannot be achieved through process improvement alone. The product owner can make a call between two competing priorities in the knowledge that the call will hold. The team can take on work that is genuinely hard, technically ambiguous, or outcome-uncertain, without the implicit pressure to select for completion rate. The sprint review becomes the kind of conversation that changes what happens next: a stakeholder raises a concern, the product owner has the authority to act on it before the next planning session, and the team enters planning knowing that the goal they are about to receive reflects the organisation’s current best understanding of what matters most. The backlog is shorter than it was six months ago, not longer. Every item on it exists because someone who can see what each item is worth relative to the alternatives decided it belonged there, and had the authority for that judgement to hold.
None of this requires a different framework. It requires the conditions within which the framework can function. The ceremonies are the same. The cadence is the same. The artefacts are the same. What is different is that the principle the framework was built on is actually operating. The framework was never the variable. The structure surrounding it was.
The framework was never the variable. The governance conditions, the authority model, and the definition of value surrounding it were. Fix those, and the ceremonies do what they were always designed to do.
If the pattern described here is familiar, the starting point is not a backlog audit. It is a question audit. These are the questions worth asking before the next sprint planning session.
These questions have answers. In teams where Value-Based Prioritisation is genuinely operating, the answers come quickly and with confidence. In teams where it is not, the questions themselves tend to produce discomfort, because they expose assumptions that have been embedded in the planning process and left unexamined. The velocity chart never asks them. The stories are accepted without requiring them. The ceremonies run regardless of whether anyone could answer them.
The discomfort is diagnostic. It is not a sign that the team is doing something wrong. It is a sign that the structural conditions for the principle have not been put in place. Those conditions are designable. The authority question, the value definition question, and the backlog governance question all have structural answers. What they require is the willingness to ask the questions clearly enough to see where the gaps are.
Velocity will continue to be a useful planning tool once it is no longer the primary success metric. The sprint review will become more demanding and more valuable once it is anchored to outcomes rather than deliverables. The product owner’s role will become considerably more interesting, and considerably more effective, once the authority matches the title. None of these changes require dismantling the Scrum ceremony structure. They require the governance conditions and the decision-making authority that allow the ceremony structure to do what it was designed for. That is a solvable problem. The structural conditions that produced the pattern are designable, which means the conditions that resolve it are too.
Orchiture’s System Diagnostic is a structured, evidence-led assessment of how work flows through your engineering organisation: where value is defined, where authority over prioritisation actually sits, and what structural conditions are preventing the team from building the most important thing. It takes three weeks and produces a root-cause report your leadership team can act on.
Start a conversationShorter versions of each piece appear on LinkedIn first — the problem, in a post. If you find yourself nodding, the full article is here. Follow for the problem-first content that comes before this page.