Prev Next

The Backlog

The Backlog (or Product Backlog, as it is called by some Agile methods such as Scrum) is an ordered list of items that will deliver business value to the customer. It can consist of a heterogeneous list of item types ranging from Features, User Stories and Requirements (including Non-functional Requirements) to Defects, Changes and more. In fact, in Enterprise Architect any element can be placed onto a Backlog; the ones that are listed and those that appear in the Toolbox are simply the most common. The Backlog is an ordered list based on the business value, with the higher value items percolating to the top of the list. The list is owned and managed by the Product Owner or their equivalent; that is, someone acting as a surrogate for the customer.

Ordering Items in a Backlog Lane

When working with a one-stage workflow, the Backlog items will typically be contained in the first lane of the Kanban and can be dragged to a new location in the lane to change the order of items in the backlog.



See also


Select the Item to be moved in the Backlog diagram.


Drag-and-drop it into a new location in the backlog lane.

Prioritizing a Backlog

Typically, the order of the items in the Backlog is carefully and thoughtfully determined by the Product Owner and reflects the business value - the items promising high business value are located at the top. The prioritization of the Backlog is the Product Owner's responsibility, but it is not decided in isolation from other team members and the Product Owner relies on access to important information from a range of stakeholders, from senior executive level stakeholders, business and operation managers, requirements analysts and business analysts, through to implementation teams.

A range of strategic diagrams and materials provides a source for many of the prioritization decisions. These include: Strategy Maps, Business Drivers, Goals and Objectives, and Roadmap diagrams that describe the time-based sequencing of packages of work. The example Roadmap diagram could be used by the Product Owner as an input to what is of high priority to the Business, or what has been planned by the Enterprise or Business Architecture teams. The diagram will prove useful in discussions with both the business stakeholders and the implementers, who can gain a business context for the work they are completing.

A Roadmap diagram in Sparx Systems Enterprise Architect showing development stages.

Comments provided by Implementers and other stakeholders will also provide a valuable source of information and input into the prioritization of the backlog. Enterprise Architect has a Discuss & Review window, which is a highly collaborative facility through which any team member can enter discussion posts against an element and other users can reply and join the discussion. This can create a rich and useful tapestry of knowledge that will not only help the Product Owner in deciding the item's position in the backlog list but will also assist implementers when they are ready to implement the item.

Showing element discussion for a user story in Sparx Systems Enterprise Architect.

Another critical piece of information that will help the Product Owner is the item estimates completed by implementers, who make their best estimation of how long the item is likely to take. Agile teams using User Stories tend to use Story Points, but any unit of measure can be used as long as the team agrees upon a standard. Some teams will use actual times based on units such as number of hours, whilst others will use effort-based estimates. Enterprise Architect has a flexible and integrated resource allocation facility where team members can add estimates, allowed time, actual times, completion percentages and more. This will be invaluable for the Product Owner, who might have a broad idea of the time required to complete an item but who would rely heavily on the details supplied by the team. The time estimate can be entered in the 'Expected Time' field of the Resource Allocation window.

Showing two resources being added to an element in Sparx Systems Enterprise Architect.


This diagram shows how a backlog can be defined in a one-stage workflow, allowing items to be dragged and dropped in a single column to define the order of the items in the backlog.

Showing a backlog lane in a one-stage workflow Kanban Diagram in Sparx Systems Enterprise Architect.

Ordering Items in a Backlog Diagram

When working with two or three stage workflows the Backlog items are contained in a Kanban board representing the entire Backlog, allowing them to be moved between lanes from low to medium, high or critical or using any user defined lane names or bound property.



See also


Ensure the Backlog Kanban diagram is open.


Select the work item to be prioritized in the diagram.


Drag and drop the item into a new location, either in the containing lane or in another lane.

Securing a Backlog

The Backlog is a communication tool that insulates the implementers from the need to decide what they should be working on. It is owned and managed by the Product Owner, who ultimately decides what should be on the Backlog and the order of the items it contains. It therefore must be secured from inadvertent changes. The implementation team should have access to the Backlog, but for the purposes of pulling items from a work queue to the In-Progress lane, which could be continuous flow-based (Kanban) or time-boxed (such as a Sprint). The development team also need to provide time estimates for the items in the Backlog, which will help the Product Owner decide upon the order of items, particularly when two or more items have comparable business value. The item with the lowest completion estimate will typically be given a higher position. Developers are also expected and encouraged to comment on the items in the Backlog so that the Product Owner can understand any issues or have access to learning from prior initiatives or insights.

Enterprise Architect's security system can be used to lock the Backlog while still allowing people to make the necessary contributions of time estimates and comments in the form of discussions.

With the Security System enabled and either a group for Product Owners or individual users who are Product Owners added, a Backlog diagram can be locked by the individual Product Owner user or a member of the Product Owner group. This example shows the Backlog being locked by the Product Owner group, but for a repository that is accessed by a number of Product Owners it could be more expedient to lock the diagram to an individual.

Locking a diagram so that only members of a security group may edit it, in Sparx Systems Enterprise Architect.

When the Backlog diagram has been locked by the Product Owner, other team members will be able to view the diagram but a small red marker to the left of the diagram name in the Browser window will indicate that it is locked. The Project Manager will see a blue marker indicating that they have access to edit the diagram.

The Project Browser showing the backlog diagram locked in a Kanban two-stage workflow in Sparx Systems Enterprise Architect.

Securing a Backlog Diagram

Secure a Backlog diagram, remembering that it can be locked at a user or a group level.



See also


Locate and select the Backlog diagram in the Browser window.


Right-click on the diagram name and select the 'Lock Diagram' option. The 'Lock Diagram' dialog displays.


Select the 'User Lock' or 'Group Lock' option from the 'Lock Type' list.


Select the User, or the Group from the 'Group ID' drop-down list.


Click on the OK button to save the changes.


  • The model must have user security enabled in order to lock the backlog Kanban diagram
  • To secure a Backlog a two or three stage workflow is required where the Backlog is a separate Kanban diagram