DBT Framework for Story Implementation

by Alex Yakyma
Define-Build-Test (or DBT) is one of the seven agile practices that scale (see "Scaling Software Agility" by Leffingwell). And even though organizing successful agile development at scale is a sum of a whole number of techniques and approaches, DBT paradigm is something to start with as it is the most important step to efficient value creation.

Let’s consider the anatomy of a DBT effort.


Product owner defines a story for the team so that it is understandable enough to be estimated and so the team could commit to deliver the story within a sprint. A developer writes the code that implements the functionality of the user story and tester performs the verification. These are the three logical steps that each DBT team performs. Although there is a number of important nuances relevant to successful deployment of this practice. Let’s consider them in more detail.

Roles overlap. Developer and tester may very actively contribute to the definition. Product owner may sometimes help them test it (in fact, it is not uncommon that product owner writes cucumber tests, for example). Developers may and actually should help testing it via implementing module and unit test as well as system tests. Testers may help with the implementation; I had a chance to witness that as well. Although it is still very important that only product owner can accept (or not accept) the ideas that define the functionality. Same way developer and tester have their exclusive authority to decide how to implement the story. At the same time:

The role overlap is the evidence of effective self-organization within a DBT team, it fosters creative thinking and innovation.

Iterative nature. It is important that the team performs all the three “steps” in creating user value, however it is also crucial how exactly they do that. If a DBT team performs these steps sequentially and in a single pass then they are actually “waterfalling” the story implementation. Here are the reasons why this is not a very good idea:


• Product owner has no chance to efficiently re-define the story
• Batches between the “steps” are too large
• Developers and testers have little chance to efficiently manage technical risks

Indeed what happens is a big batch of story scenarios, business rules, and conditions create even bigger batch of conditional flows, data structures and interfaces that in turn influence testing. Uncertainty of the outcome grows disproportionally. Also these large batches inhibit feedback and communication within the DBT team. And even more importantly:

If the team fails to deliver full user story within a sprint, they deliver zero user value.

There is an alternative way – a multi-cycle DBT effort. This way we reduce the batches because instead of “passing” the entire whole story to implementation, we take a slice of value at a time. Same way as we split user stories into smaller stories, we split story into slices which we don’t have to consider as stories (no need to estimate them, or write acceptance criteria separately for them and so on). A good set of approaches of how to do it can be found in a post by Bill Wake . In this case DBT-effort looks like this:


This way we avoid the “snowball effect” of batches which helps keeping the outcome within much more predictable time boundaries. Also a “vertical slice” of a user story gives the product owner immediate opportunity to evaluate her assumptions. Developers and testers also drive out most of the risks this way, because this tiny slice goes thru the entire system vertically and makes all the system layers “work together” to perform a valuable function. We have selected just one of the examples of splitting story into two DBT cycles based on “Main functionality – Everything else” approach. But there can be many other ways too. Also, there can be more than just two such cycles.

Another important takeaway is that:

Effective product owner works with the team at the level of a DBT cycle, which supports effective just-in-time requirements elaboration.

Now, if the team fails to deliver the entire scope of a story they can still finalize their current cut of the story (the output of the currently finished DBT cycle) and, if the product owner accepts that, count it as user value (say 3 points out of a 5-point story). With this approach teams understand their velocity better as well as their burn-down chart becomes more reliable sprint tracking tool.

DBT formations. Even though we call an individual agile team a DBT team emphasizing that they can define and implement their each backlog item, the implementation of each user story is not precisely done by the whole team. Instead, DBT formations self-organize around each user story.



DBT formations have the following characteristics:

• They are the groups of at least 1 developer, 1 tester and the product owner
• Product owner is always shared across multiple DBT formations within the team
• A DBT formation emerges around a user story and dissolves after the story is completed

In other words, DBT formation is a small team, a subset of the agile team they belong to. It emerges and lives for as long as the user story requires and then the new formations organize around the next stories and so on. Efficient dynamics of DBT formations foster:

• Collective code ownership
• Continuous refactoring
• Knowledge sharing
• Quality

Indeed, team members rotate across different areas of the codebase each time they organize into DBT formations and thus exchange information very efficiently within the formation itself as well as with the rest of the team. Also they keep the code clean because each time they encounter someone else's code that already starts smelling, they just improve the design so that a) they could effectively work with it and b) other DBT formations could add new functionality faster in the near future. The quality of the system functionality maintains high because DBT formation starts catching defects in early cycles which minimizes required rework associated with bug fixing during the implementation.