Jump to Menu

Sending Multiple Sources of Requirement to Backlog

A simple yet extremely powerful feature for the agile development process.

A software project, especially a large-scale one, typically have requirements identified from different sources or, in other words, different models. For example, project teams that adopt PMBOK® might identify most of the major work packages from a work breakdown structure diagram in project planning. Once the various project baselines have been approved, the team will receive necessary resources and funding to move forward. The work packages will be drafted into the software contract, either developed in-house or outsourced. After a detailed studying of a software system (or the work packages) some detailed requirements might be developed/discovered from the use case approach, or alternatively by comparing the gap between an as-is and to-be process diagram. Requirements can be found from different steps and from different models throughout the whole process.

Consider a software team need to manage requirement identified from some many different sources such as:

  1. Directly from Agile story map
  2. Use case approach
  3. Brainstorming or mind map
  4. Business process diagram
  5. Work Breakdown structure
  6. PERT Chart
  7. Etc.

Dealing with multiple source of requirements with 'Send-to Backlog'

Consider the "Send-to-Backlog" analogous to "Share" or "Send-to" in smartphone, when you want to share a piece of information among apps, such as an image, screenshot, or a word.

Now, the send-to backlog idea can be used in any diagrams constructs (shape like use case). Consider a candidate of a User Activity could be sent over to the backlog in a Story Map, and then the software team can sort them base on their priorities and difficulties, and subsequently break them down into User Tasks, Epics and user stories in an organized way.

Dealing with Multiple Source of Requirements with Send-to Backlog

The traceability among models

When you do the sharing, not only a transfer of the shape model from the diagram to the backlog of story map is performed, but also the traceability link between both sender - shape to the receiver a user activity. And the user activities are subsequently broken down into user tasks, epics and user stories in a hierarchical way. Actually, the traceability in Visual Paradigm is maintained nicely from the sender, to receiver, and all the way to Epics and user stories. You can visually see those traceability indicator attached in shape, progress indicator, or popup menu of the shape's corresponding model.

The Traceability among models

"PMBOK" is a trademark of the Project Management Institute, Inc. which is registered in the United States and other nations.

"TOGAF" is a trademark of The Open Group, which is registered in the United States and other countries.

Turn every software project into a successful one.