Managing a 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 comprise 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.

Prioritizing a Backlog

The order of the items in the Backlog typically 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 and business analysts down to implementation teams.

A range of strategic diagrams and materials provide 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.

Implementers' and other stakeholders' comments will also provide a valuable source of information and input into the prioritization of the backlog. Enterprise Architect has a Discussion 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.

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 relies heavily on the details supplied by the team. The time estimate can be entered in the 'Expected Time' field of the Resource Allocation window.

Example

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.

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.

Example

This diagram demonstrates a Backlog diagram in a two or three stage workflow. The entire diagram is used to manage the backlog and items can be dragged within a lane to define their order in that lane, or between lanes to define their importance and position in the backlog.

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.

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 Project Browser will indicate that it is locked. The Project Manager will see a blue marker indicating that they have access to edit the diagram.

Securing a Backlog Diagram

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

Notes

• 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