LEARN. PRACTICE. GROW.Identify existing discretion
A team cannot remove an external approval but can improve request clarity. The optional 15% Solutions pattern, developed by Henri Lipmanowicz and Keith McCandless, invites actions within existing authority and resources. Its name does not require reserving 15% of the budget or Sprint. Here, the local action is testing a request description that reduces clarification. The external dependency remains visible and receives its own treatment. Small initiative is neither an excuse to ignore the main constraint nor authorization to change a control owned by someone else.
Observe flow without rewarding accumulation
The queue starts with eight items. Seven enter and four finish during the week; with no other entries or exits, eleven remain. Repeating that pattern increases accumulated work. This calculation is a simple balance, not a model automatically forecasting individual deadlines. Discuss why management rewards starting rather than useful completion. Observe waiting, blocked work, and quality effects before selecting a change. Do not compare teams by points or impose a universal limit from these numbers. The experiment should address the observed problem and actual collaboration conditions.
Bring feedback forward while retaining controls
A required security check occurs after many changes accumulate. The team can explore smaller-batch feedback with the control owner. Record what remains mandatory and what can change in the process. Measure time to detect incompatibilities, rework, quality, and effort in the involved function. More checks without capacity may simply move the queue. Facilitating collaboration does not make the Scrum Master a technical approver. The final decision should include effects on the integrated product and on teams receiving more frequent requests rather than reporting only faster local development.
Measure the user journey
An interface reduces one step from six to four minutes but requires three executions instead of two. In this model without other steps, total time remains twelve minutes. The local improvement did not reduce journey effort. Add success and quality criteria: fast execution with an invalid result does not create the expected benefit. At the Sprint Review, include evidence from operators across shifts and discuss adaptations with relevant stakeholders. The Product Owner remains accountable for effective Product Backlog management, including product-related reliability and operational improvements.
Plan with support and uncertainty visible
Known support work consumes capacity in the next Sprint. Developers should consider that information when selecting work and building the plan with the Product Owner. Do not compensate for support days by reducing quality or promising invisible work. If a pilot included only simple requests, record that limitation before proposing adoption for critical requests. Define criteria for continuing, adjusting, or stopping the experiment, including unwanted effects. Lacking a universal conclusion does not prevent a bounded, reversible decision. Help the organization learn with context instead of turning a local result into a permanent rule.
Bring a concrete proposal to the external owner
In the final exercise, clearer requests reduce rework, but most time remains in external approval. Prepare a discussion with the observed population, timings, control purpose, and alternatives preserving that purpose. Propose a bounded trial with agreed participants, observation, and review. The external owner should understand the change and their authority; the group should know which decisions remain open. Do not use agility to waive controls or to reject every adaptation. The intended result is an experiment that makes the product more useful and the flow easier to understand.
# Synthetic arithmetic; no lead-time or causal guarantee
queue_after = 8 + 7 - 4 # 11 items
journey_before = 2 * 6 # 12 minutes
journey_after = 3 * 4 # 12 minutesQueue: 8 + 7 − 4 = 11 items. Journey: 2 × 6 = 3 × 4 = 12 minutes. The models show accumulation and limits of a local improvement.
Common pitfalls
Confusing initiative with authority; measuring only one step; extrapolating simple requests to critical ones; hiding support work; imposing a pilot as a universal process.
Related topics: Facilitate participation and difficult decisions · Coaching, mentoring, teaching, and leadership · Organization, incentives, and systemic barriers
Improve the system through bounded experiments with explicit authority, population, and outcome. Decisions should consider the whole product.
Reference: 15% Solutions · PSM II; Scrum Guide November 2020; no public numbered exam revision