In these cases, the best approach is to align how these definitions should be created, if they should be created, with the stakeholders who have the greatest influence and impact on the project. I will leave here another article that I wrote about this topic called “Stakeholders – improving your power and impact.”

If you are already a leader with enough influence and autonomy, I will first share the concepts from SAFe and then explain how I use them in practice. This is also the kind of problem that Saint Jude helps leaders observe more clearly: tasks that enter the board without enough clarity, estimates that do not match reality, and risks created by poor task definition.

SAFe's definition of ready and definition of done

Shift learning left

Product development includes many unknown scenarios that the team will discover as the project progresses, and the same is true for individual tasks. The later these scenarios are discovered, the harder and more expensive they become to adjust, impacting scope, quality, schedule, and costs. For this reason, having a process to verify and validate possible scenarios early becomes crucial for the healthy progress of a project.

Pair programming and peer review

This is a valuable and well-known practice, but it is still rarely used consistently by technology teams. Two professionals work together on the same task: one focuses on building the solution, while the other acts as a navigator, providing feedback and suggesting improvements in real time. The idea is to bring more than one perspective into how the task should be built, increasing not only product knowledge but also the team’s understanding of how the product works internally.

Collective ownership and T-shaped skills

Here, SAFe tells us that every person within the team should have the skills and enough authority to modify a delivery, regardless of where that delivery is in the process. No single professional owns the delivery or the product. Another important point in this concept is to have professionals who, even while being specialists in one type of work, also understand the project as a whole.

Artifacts standards and definition of done

Deliveries often depend on manual processes to move tasks between professionals within the same team, which can generate delays. Inside these product construction processes, there is also time lost inspecting tasks or searching for components that already exist and could be reused to speed up delivery or improve performance. Automating these processes helps reduce time and costs, increase productivity, and improve delivery standards.

Workflow automation

Workflows often include manual handoffs between professionals within the same team, creating delays and reducing flow efficiency. During these construction processes, teams may also lose time inspecting tasks manually or searching for components that have already been created and could be reused to accelerate delivery or improve performance.

Automating these processes helps reduce time and costs, increase productivity, and improve delivery standards. In practice, this is closely connected to what Saint Jude tries to make visible: where tasks are waiting, where the workflow is inefficient, and how unclear work can impact schedule, cost, and delivery performance.

These concepts are part of what SAFe understands as built-in quality. As you may have noticed, the Definition of Ready (DoR) and the Definition of Done (DoD) are not isolated ideas. They are part of something bigger: quality.

Now, let’s move on to how I use these concepts to create a better Definition of Ready and Definition of Done in the projects I manage.

Definition of ready/done and quality in practice

To create clarity and improve documentation, I use a tripod formed by the PO, UI, and tech leader to build the Definition of Ready for any task, using the following structure:

• UI documents the expected flow and alternative flows
• PO documents what is expected as a business delivery
• Tech leader documents how it should be built

Why? Honestly, I have never seen a project where all team members have the skills and authority to make every decision. Because of that, it becomes necessary to create technical and business leadership among the interested parties to guide and validate the tasks. Based on the experience I have acquired, having someone to guide the team technically is necessary until the team becomes self-sustainable.

For the Definition of Done, I also use these professionals to validate and formally finish the delivery. That said, I will now explain this in more detail using SAFe’s concepts.

Shift learning left

In this case, with the initial documentation provided by my tripod of professionals, the development team can start building the task through tests, using the famous TDD approach, while the QA team can already work on test scenarios using BDD. I can also bring in a concept from the agile world: if the team does not understand what should be done during refinement events, the task is not ready to enter the sprint. From this point, we return the task to the tripod with all the questions raised by the team, and we refine the documentation until the task is crystal clear to everyone.

Pair programming and peer review

I love pair programming, but I will bring up an uncomfortable truth that almost nobody has the courage to say:

“If you assign two people to work on one task instead of two people working on two different tasks, either you have considerable influence inside your company, or your boss may not be happy with you.”

The truth is that almost nobody wants to sacrifice time in favor of quality. That said, one action I always apply with my teams is that my tripod — PO, UI, and tech leader — serves as a group of oracles during the construction process. No matter how much time we spend documenting what needs to be done, questions can still appear in the middle of the work. The faster we answer these questions, the faster we move forward. In general, I ask this tripod to reserve one hour per day to answer questions. It works almost like a daily meeting, but with more time for complex explanations.

Collective ownership and T-shaped skills

Here again, I rely on my tripod of professionals as the people responsible for any modification to the tasks. But why?

At the beginning of a project, or even when new professionals join, their knowledge and experience are usually zero or very low regarding business rules, what needs to be done, and what is expected from the deliveries. For this reason, they depend on the knowledge of people who have more time on the project or more experience, such as the PO, tech leader, and UI. These are the people who have the keys to enter and modify any process or delivery. Over time, the team gains confidence and becomes able to intervene in any phase of the process.

However, there is a specific point here: human beings are naturally attached to the authority they have earned. If you suddenly remove someone’s previously conquered authority, you may create behavioral problems, sometimes even leading to resignations or layoffs. On the other hand, when these professionals go on vacation, you will already have a trained team capable of modifying deliveries when necessary.

Finally, about T-shaped skills: using Pareto’s rule, I would say that in 80% of cases, this simply does not happen. First, because it takes a lot of time to gain broad knowledge, and projects do not always last long enough. Second, because it is difficult to find professionals interested in learning a little about every new topic involved in product construction.

Artifacts standards and definition of done

Now we will enter a little more into the Definition of Done, but first I will start with standards. Every professional has work patterns, and when these patterns are documented, they become the project’s patterns. I will open an exception for patterns that come from outside, such as company standards or PMO standards. In any case, standards exist, and they influence how work is delivered.

Regarding the Definition of Done, I mentioned before that one of the key points is validation and formal acceptance by my tripod. In addition to this, I use test cases and unit test automation as part of the Definition of Done. The main reason is to create a safety lock and avoid problems in production. If the tests fail, the product is not ready for my customers.

Workflow automation

To bring more agility to the process of finishing tasks, from the moment they start until they are completed, the best approach is to balance what needs to be done with the number of people available to do it. If you need to choose, it is better to have people waiting for tasks than tasks waiting for people. In the end, we want to deliver a product quickly and with high quality, don’t we?

Regarding task inspection, when test cases and unit tests are automated, manual inspection becomes less necessary. Finally, the search for components can be described in the task’s initial documentation. If it is not, one of our oracles should be able to answer it. This is also where tools like Saint Jude can create curiosity for leaders: when task clarity, estimates, flow, schedule, and cost are analyzed together, it becomes easier to understand whether the team is truly productive or simply busy.

I have reached the end of this article. Here, you learned some SAFe concepts about quality and how I use them to create efficient Definitions of Ready and Done for my projects.

Do you want to continue this conversation? Like the article, comment on LinkedIn, or share it on your social media.

See you soon!

Erik Scaranello