Organisations continuously receive requests to improve existing services, introduce new capabilities, respond to regulatory requirements, or support changing business priorities. The challenge is not only generating ideas, but deciding which development needs should move forward and when development capacity should be committed.
Prioritisation, commitment, and backlog management ensure that development capacity is directed towards the initiatives that create the most value. At the same time, they maintain a continuous flow of work through the development lifecycle while balancing responsiveness, governance, dependencies, and resource constraints.
Not every valid development need should move immediately into implementation. Development requests must be evaluated against business value, urgency, feasibility, dependencies, risks, and available development capacity.
Prioritisation takes place at several levels. Larger initiatives are prioritised through portfolio and value stream steering, while smaller improvements and service changes are often prioritised closer to the operational development flow.
The roadmap represents prioritised business intent and planned capability development. The backlog represents committed development work. This distinction is important because roadmap items may express important business needs without yet having confirmed funding, ownership, implementation readiness, or development capacity.
Before development work is committed, there should be sufficient understanding of:
The Business Owner is accountable for the business rationale, expected value, and commitment decisions related to development. Prioritisation and backlog refinement are typically coordinated by the Product Owner together with business and development stakeholders.
Different demand types require different levels of governance and planning. Capability planning and ideas or concepts often require broader portfolio steering and business design before implementation commitment is made. Increments, improvements, and service changes can usually move faster into implementation when ownership, feasibility, and capacity are clear.
Prioritisation determines the order in which development work is executed. The objective is to maximise business value while maintaining a realistic and sustainable development flow.
In gate-based development, prioritisation typically takes place at portfolio level, where initiatives compete for funding, resources, and implementation capacity. Decisions are influenced by expected business value, urgency, risk, dependencies, compliance requirements, and strategic importance.
In sprint-based development, prioritisation happens continuously through backlog management and iterative planning. Larger development needs are managed as epics and require portfolio decision before implementation commitment, ensuring that significant investments are evaluated consistently regardless of development method. Approved epics are then refined into features, stories, and other executable backlog items that can be delivered, validated, and adjusted during development.
Development planning provides a common coordination mechanism across both gate-based and sprint-based development. In larger transformations, development planning aligns projects, development teams, dependencies, releases, and development capacity within the same end-to-end flow. Where development spans several teams, an increment plan can be used to coordinate expected contributions and dependencies for a defined period.
The Development Management Office (DMO) orchestrates portfolio management and development planning across end-to-end flows. It supports prioritisation, improves visibility into development capacity, improves visibility into development capacity, and helps resolve dependencies, resource conflicts, and prioritisation challenges between teams, value streams, and development initiatives. Although the governance and planning models differ, both approaches require disciplined prioritisation and transparent commitment decisions.
The backlog is the central mechanism for managing committed development work. It is not a wish list or a collection of loosely defined ideas. A backlog contains development items that are sufficiently defined, prioritised, and ready for implementation. In sprint-based development, backlog structures typically include epics, features, and user stories that are refined continuously throughout the development flow.
In BTS, backlog-driven execution is also used in gate-based development. A project may use gates for investment decisions, scope control, rollout approval, and governance, while implementation work is refined and coordinated through backlogs. This allows sprint-based development teams to contribute to larger projects without weakening either gate-based governance or sprint-based delivery discipline.
Gate-based and sprint-based development can therefore be combined within the same end-to-end flow, while each development practice retains the discipline required for effective delivery and governance. Effective backlog management improves visibility, coordination, prioritisation, and development flow control. It also enables organisations to adjust development priorities continuously as business needs, risks, or operational conditions evolve.
Commitment represents the decision to allocate development capacity and proceed with implementation. In gate-based development, commitment is typically formalised through development approval, funding decisions, and project governance. In sprint-based development, commitment is reflected through backlog selection, iteration planning, and development team capacity allocation.
Regardless of the development approach, commitment should only be made when requirements, feasibility, ownership, and implementation readiness have reached sufficient maturity to support realistic delivery. Once development work has been prioritised, committed, and refined into executable backlog items, the focus moves to design, development, and validation.
