Three Stage Workflow

The Three Stage Workflow pattern creates three Kanban boards that can be used together as a workflow with three parts: a Backlog board, a Development board and a Release board. Items can be added from the toolbox or the Project Browser and moved between lanes and between the three boards.

Figure 1: Part of the Release Board showing the Development and Backlog  Board -Drop Targets allowing items to be moved between the three boards that make up the workflow.

Figure 2: Part of the Backlog Board showing the Development and Release Board - Drop Targets allowing items to be moved between the three boards that make up the workflow.

Discussion
The goal is to allow items (Features, User Stories, Defects, Changes and more) to be visualized as they move through a workflow from being considered as part of a Backlog through to being fully developed, released and deployed. The elements that appear on the boards can be elaborated in other diagrams and connections can be made to a range of up-stream elements such as business requirements, business process and down-stream elements such as Components and Services.

This pattern is used when you want to manage the Backlog as a separate board. In contradistinction to a one stage workflow items in the backlog can be moved between the lanes on the backlog board to indicate priority. Once  the items reach the critical lane they can be dropped on the Development Drop target which will place them into the first (Queue) lane of the development board - indicating they are ready for development work to begin.

The following is a list of some things you may want to do when working with this pattern.
·	Rename the items in the diagrams to suit your initiative.
New items can be dragged onto the diagram from the Toolbox or the Project Browser.
Items can be moved between lanes on the Backlog, Development and Release Boards to change their Priority.
Items can be moved from the Backlog Board to the Development Board by dropping them on the Drop Target at the far right of the Backlog Board.
Items can be moved from the Development Board to the Release Board by dropping them on the Drop Target at the far right of the Development Board.
Items can be moved between lanes to indicate their position in the workflow.
Items can be moved from the Development Board back to the Backlog by dragging them to the Backlog Drop Target at the far right of the board.
One or more Resources can be allocated to an item on either board by Selecting Resource Allocation from the Task Management Panel of the Construct Ribbon.

The following is a list of some of the next steps available when applying the pattern.
·	As  items such as User Stories and Defects  move across the backlog board towards critical or are moved to the Queue lane of the Development Board they can be groomed for development work.
Resources can be added to items indicating who is doing the work and what stage of completion it is at, more details can be viewed in the resource allocation window.

·	Expressive visualizations can be achieved by creating Dash Boards and Charts that help to show the progress of an element on the board.

Reference
The following are some of the tools that will be helpful when working with this pattern.
Kanban Features
Allocating Resources to Work Items
Creating and Viewing Requirements
Gantt View
Dashboard Diagrams
Changing Element Appearance
Changing Diagram Layout

The following tools are useful when working with this pattern.
Kanban
Kanban diagrams can be used to manage a wide range of items in Enterprise Architect including User Stories, Requirements, Defects, Issues, Risks and more. The facility provides one or more Kanban boards that can be related to each other in a visually compelling and easy to work with tool. Workflows can be created that allow the management of items by different groups including product managers managing backlogs and implementation teams managing development teams. For more details see the Kanban help topic.
Resource Allocation
Resource Allocation can be used to manage resources and track how work is progressing against predefined estimates.  Resources can be defined as repository reference data and then one or more resources can be allocated to a model element. The allocation can be done in an agile way where a resource simply identifies a task or element that needs to be completed and allocates themselves or the allocation could be done by a project manager. Sophisticate and compelling charts and dashboard diagrams can be generated automatically given a powerful representation of the progress. For more details see the Resource Allocation help topic.
Element Discussions
The Element Discussion facility is a fully featured collaboration tool allowing modelers and model viewers and reviewers to communicate with each other directly inside the repository. Modelers using the full client or occasional viewers using WebEA can both post and reply to discussions and communicate and engage in chat. For more details see the Element Discussions help topic.
Calendar
The Calendar provides a way to record and present important temporal information such as events and meetings in calendar format. Collaborative Games can be entered into the Calendar and setup as recurring if needed. Event subtypes can be configured to add Collaborative Games as a Meeting Type. For more details see the Calendar help topic.
Model Mail
Model Mail can be used to notify and remind people of a Collaborative Game and to notify them after the game has been played about outcomes and decisions and required actions. Links to model elements and diagrams, matrices, team reviews and a variety of other items can be added.. For more details see the Model Mail help topic.
Document Generator
The Document Generator is a powerful facility in Enterprise Architect that allows a Database Engineer or other stakeholder to create high quality corporate or technical documentation directly from the model, suitable for internal or external audiences. For more details see the Documentation help topic.
Specification View
The Specification View can be used as a way of working with the Components and Interfaces particularly when there are a large number of elements as is typically the case when describing a system of any appreciable size. For more details see the Specification View help topic.

© 2000 - 2018  Sparx Systems Pty Ltd.  All rights Reserved.