DDS Guide: How it works

Below are the key concepts used within the DDS Framework.

Artifacts: A Backlog Item (BItem) may take a variety of forms such as “user stories”, “experiments”, or “testable hypotheses” as popularized by XP and Lean. The Item Backlog is a prioritized list of BItems (i.e., work to be done). The Item Breakdown Board (IBB) is the place where each Item (in the item backlog) is broken down into tasks, with at least one create task, one observe task and one analyze task for each item. Items on the product backlog are broken down to into their component tasks prior to being worked on by the team, and each item has its own IBB. The Task Board is a visual representation of the work items currently in progress. For work on an item to be started (i.e., being worked on by the team), the tasks for that item are moved from the IBB to the Task Board and are displayed on the board, typically in the ‘to do’ column (items not yet started are on the item backlog). The task board has several columns (at a minimum, ‘to do’, ‘in progress’, ‘done’) and each task flows across the board, thus visually showing work being done within the team. As with Kanban, to facilitate task throughput, each team defines a maximum number of tasks within a single column.

Iterations: An Iteration is a collection of one or more backlog items. Due to the task breakdown (in the IBB) for the item, each iteration will have one or more observation and analysis tasks. The information gained from the iteration must have business value derived either from the thing that is created or the analysis of the task completed. Furthermore, each iteration should aim to be a minimally viable set of work that can deliver value and allows the given lean hypothesis to be tested, and should not last more than one month, but can be as short as the team wants (e.g., one day). The team breaks this set of one or more BItems into several tasks (via the IBB) that the team collectively strives to complete as soon as possible. These tasks are placed on the Task Board, in the ‘to do’ column. The current status of these items is always visually represented on the Task Board and the iteration is completed when all the tasks for that item are in the ‘done’ column.

Roles: Similar to Scrum, each DDS team is a group of three to nine people, one of whom is the product owner, and one of whom is the process master. If either the product owner or process master do not contribute to executing the work of an iteration then they do not count towards the nine person maximum or the three person minimum. As in Scrum, the product owner in DDS is the empowered central point of product leadership – the person who decides which features and functionality to build, the order in which to build them, and what aspects of them to observe and analyze. The product owner owns the Item Backlog and is responsible for prioritizing its BItems, ensuring that each BItem is clearly defined, and that the upcoming work and priorities of the team are visible and transparent. In addition, the product owner must agree that the tasks in the done column are actually done (a simple way to achieve this is to add an addition column ‘confirmed done’ to the task board). The process master (DDS master) acts as a coach, facilitator, impediment remover as well as helping everyone involved understand and embrace the DDS values, principles, and practices to aid the organization obtain exceptional results from applying DDS.

Both the task owner and the process master are part of the DDS Team and may contribute to creating, observing and analyzing throughout an iteration. Finally, the DDS team should be comprised of a cross-functional collection of people that have all the skills needed to design, build, test and deploy the desired product. The team self-organizes to determine the best way to accomplish the goal defined by the product owner.

Refining and prioritizing: In addition to the DDS team working on one or more iterations, the team also spends time refining and prioritizing the BItems, which is the activity of creating, refining and prioritizing potential iteration items and breaking down the items near the top of the backlog. The product owner, with input from the stakeholders and the other team members, is responsible for maintaining the product backlog, which evolves and changes throughout the project. While the product owner owns the prioritization process, the other members of the team typically budget 5% to 10% of their total capacity to assist the product owner with product backlog refinement (e.g., breaking an item into two smaller, but still useful, items, clarifying or simplifying an item, etc). As part of the refinement process, the team defines a relative unit of measure, decided upon by the team, to provide relative an estimate of the effort for completing different items. This effort estimation, which could, for example, be a T-Shirt sized view of the work to do (large, medium, small), or be a number representing relative effort, is used to help prioritize backlog items, but not define what is part of an iteration.

Events: There are several events that are key aspects of DDS, and which help the team stay coordinated.

  1. Daily Meeting: occurs each day, when the team meets for a 15-minute inspect-and-adapt activity. An important goal of this meeting is to help a self-organizing team better manage the flow of its work (ex. helping a team member get past an issue). Just as with Scrum Standups, a common approach for conducting this meeting is for team members to share with each other what they did yesterday, what they are planning to do today, and any obstacles they are facing.
  2. Iteration Review: occurs on a regular and repeating basis, and is scheduled by the product owner. Reviews might be weekly and are calendar based to account for the fact that there might be several iterations per week, and there would be diminishing returns if iteration reviews occurred on a daily (or more frequently) basis. They would also be logistically difficult to schedule if they were needed on an ad hoc basis. The review is intended to foster conversation about completed functionality and the observations and analysis that the team has generated regarding the performance of the completed iteration(s). Participants include the team, stakeholders, customers, and anyone else interested in the outcome of the project. A successful review results in bidirectional information flow. The people who aren’t on the team get to sync up on the project effort, the observed product performance, and the team’s analysis of that performance. At the same time, the team can get suggestions from the other attendees for potential features, metrics and experiments for future iterations. Furthermore, during this meeting, the group discusses the prioritization of the backlog items (since, for example, the insights gained might suggest a change in item priority or the creation of new items). At the end of the review, the tasks on the board relating to the discussed and now completed item(s) are archived.
  3. Backlog Item Selection: occurs when the team has capacity to start a new iteration (e.g., when a previous iteration has completed, or when the in progress iteration does not require full-time focus, usually during the “observe” phase). Teams may have multiple iterations in progress simultaneously, but should prioritize finishing an in progress iteration over starting a new one whenever practical. The team reviews the prioritized backlog items (that have been updated via refinement) and selects the top backlog item(s) that will now be the team’s focus. Note that since the iteration is capability-based, and is the minimally viable set of items that can deliver value, the item estimation is used to help prioritize items, not determine how many items should be included in an iteration (e.g., if two items deliver the same value but one is deemed a “small” effort and one is a “large” effort, the team might select the smaller level of effort item). Combining multiple items into a single iteration is generally only desirable in the case that the associated hypothesis or observable data overlap.
  4. Retrospective: occurs at regular intervals (ex. once a month) and is a time to inspect and adapt the process. In the spirit of continuous improvement, the team comes together to discuss what is and is not working with the current process and associated technical practices. The goal is to help a good DDS team become great. At the end of a retrospective, the team should have identified and committed to a practical number of process improvement actions that will be undertaken by the team going forward.

Comparing DDS and Kanban

The DDS framework adheres to the Kanban principles (e.g., there is a Kanban board, teams need to limit WIP, and work items flow across the board). However, the framework provides more structure than defined by Kanban, such as defined iterations as well as a more defined framework (ex. roles and meeting). Having a more clearly defined process which leverages agile best practices, will enable teams to implement the process in a more consistent and repeatable manner.

Comparing DDS to Scrum

With a few notable exceptions, DDS can be viewed as a specific instantiation of Scrum, that is consistent with the official Scrum Guide. The most important exception is that the Scrum Guide requires all iterations (sprints) to be of equal length in time. However, iterations in DDS vary in duration, so as to allow a logical increment of work to be done in one iteration (rather than defining the amount of work that can be done in a specific unit of time).  The other notable exception is that retrospectives and item reviews and not done at the end of every iteration, but rather, on a frequency the team deems appropriate. Furthermore, in many Scrum implementations, observing, analyzing and reacting to feedback is solely the responsibility of the product owner.  This part of the product owner’s job largely falls outside of the codified process.  Collecting and analyzing well-chosen data and drawing appropriate conclusions is a crucial part of the process and by building the observing, analyzing and reacting to feedback steps directly into the core workflow, DDS will help teams make better data-driven decisions.

By providing a structure for how the team should coordinate operation tasks, development tasks, and maintenance tasks without reliance on an estimated buffer, DDS enables teams to achieve continuous delivery. Specifically, DDS enables “keep the lights on” tasks to be a set of repeating tasks that go on the team’s board and “bug fix” tasks, if deemed an emergency, go straight on the team’s board as their highest priority task (perhaps as a new iteration). If the bug fix is not urgent (as deemed by the product owner), then that code fix goes on the product backlog and prioritized as appropriate during refinement and prioritization.

Table Summary

The table below provides a summary of how DDS compares to Scrum, Scrumban and Kanban. So, for example, in reviewing the table, one can see that DDS can be viewed as an instance of Kanban. With respect to Scrum, DDS can be viewed as being similar in many aspects, but DDS differs from Scrum in the use of capability-based iterations, the flexibility to not have to accurately estimate task duration and having key meetings (ex. retrospective) be calendar based, not sprint-based.

  DDS Scrum Scrumban Kanban
Iteration Capability / Item-based Time-based Time-based No iteration
Unplanned /Ops work via New task on board Buffers Buffers New task on board
Exploratory work viaWork tasks as long as neededNot DefinedWork tasks as long as neededNot Defined
Iteration &Retrospective reviews Time-based After each
After each sprint Not defined
Kanban flowNot definedKanban flowKanban flow
Task Estimation Usage Only for BItem prioritization PBI priority & What fits into a sprintPBI priority & What fits into a sprintNo Task Estimation
Use of backlog items Yes Yes Yes Yes
Backlog selection When there is capacity (to start new iteration) When sprint completes When sprint completes When there is capacity
Daily Standup Yes Yes Yes Not defined
Roles Proc Master, DDS Team member, POProc Master,Dev Team, PO Proc Master,Dev Team, PO None Defined

Scaling to Many Teams

The DDS framework is a single team framework that is designed to be compatible with the Scrum@Scale scaling framework. Each DDS team exposes the necessary interfaces to collaborate with other teams (each of which might be doing Scrum or DDS) via its roles and artifacts, while encapsulating its internal workflow. The table below summaries the touch points between the team and the rest of the organization for Scrum teams and for DDS teams.

  Team Touchpoint DDS Scrum
Product Owner Product Owner
Scrum of Scrums
Process MasterScrum Master
Product / Release
Iteration ReviewSprint Review
Metrics and
Item Backlog / TaskboardProduct Backlog /
Sprint backlog