Favro for
Agile
In any software product, there are two types of quality: intrinsic quality and extrinsic quality.
Intrinsic quality encompasses all of the qualities built into the product, including sustainability, durability, reliability, uniformity, and maintainability, essentially does it work. Intrinsic quality can be measured quantitatively, such as bugs per line of code, bugs per release, etc.
Extrinsic quality is the buyer’s perception of the product and its overall value to the customer. In short, is it what the customer needs or wants? Does it solve their problem or achieve the desired effect? This type of quality is more qualitative and can be measured based upon sales, usage, and direct customer feedback.
The goal of any development team, any technology-centric product company, for that matter, should be to maximize both intrinsic and extrinsic quality while balancing against the constraints of cost, schedule, and scope.
Essential to optimizing product quality and growing a successful business is catching defects early. The earlier either an extrinsic or intrinsic defect is detected, the less expensive it is to fix.
“Most defects end up costing more than it would have cost to prevent them. Defects are expensive when they occur, both the direct costs of fixing the defects and the indirect costs because of damaged relationships, lost business, and lost development time.” — Kent Beck, Extreme Programming Explained
The chart below shows the exponential cost increase of a bug or defect at each stage of detection in the product development cycle. Of course, one of the many benefits of agile is its focus on iterative and incremental development, shortening the development cycle, and ensuring that the all-important direct customer feedback is received as early as possible.
Even with shorter development iterations, the best way to ensure extrinsic quality (value) is to create and maintain a product backlog. With a backlog of proposed features prioritized by customer value along with closer customer collaboration, you’ll ensure that you don’t even begin developing a feature that is useless or broken by design.
The best way to create a product backlog in Favro is with a Board viewed as a Sheet. Taking advantage of Favro’s unique ability to create a hierarchy of big ideas (Epics) broken down into smaller features (User Stories) that can be developed in a single two-week iteration allows product owners or customer proxies to prioritize and plan at multiple levels.
Only the highest priority, most valuable features will ever make it to actual development. Just by visualizing your product in a backlog, you’re ensuring that only high-value features are developed, integrated, tested, and released. Couple this with more advanced agile techniques such as Definition of Ready and Acceptance Criteria, and your teams will be even more likely to catch defects before they happen, maximizing extrinsic quality and overall product value.
Say a feature is deemed worthy and is committed to a development team’s next iteration. On any high-performing product development team, quality should be built into the development process. This can be a combination of pair programming, embedded QA, automated testing, and T-Shaped developers. T-Shaped means all team members have both a deep functional or discipline-specific expertise and a broad ability to work outside of their specialty, ideally focusing on QA.
Once development begins on committed product features, both development and quality assurance should constantly overlap throughout the iteration. If possible, all defects should be detected and fixed within the same iteration.
In the example below, bugs found by embedded QA during an iteration’s time-box are added to the iteration backlog as new cards and linked to the related feature card.
If the found bugs are minor enough, they could even be entered as tasks directly on the feature card.
Defects that are not found within the development iteration are known as escaped bugs. Escaped bugs are undesirable for obvious reasons, especially if an escaped bug makes it into production and is detected by the customer.
Of course, some escaped bugs are inevitable and should be managed and resolved using the same collaboration platform as bugs found within an iteration. Even though it’s common to use multiple tools for product management, development, and defect tracking, it makes far more sense and is much more cost-effective to use a single tool for everything. It’s all one product, and everything related to it, regardless of lifecycle stage, should be managed in a single place.
In Favro, bugs that do make it out of a development iteration can be tracked and managed in a QA-specific collection with a centralized bug backlog. This bug backlog is populated with bugs found by internal QA, automated continuous integration/deployment testing, and even external QA.
Using the same bug backlog board shown above, the bug flow from Found to Fixed can be visualized and tracked by switching to a Kanban view. From this board view, bugs are pulled from left to right through whatever flow you choose.
At this point, you can use Favro automations to simplify cross-team collaboration. For example, once an escaped bug is verified and reaches a triage stage, trigger an automation that adds the bug to the appropriate development team’s product backlog.
Once in the product backlog, the product owner can easily prioritize bugs alongside features for commitment to upcoming iterations.
When the development team begins working on an escaped bug, Favro relations keep the QA team updated with real-time fix status directly from their master bug backlog.
Suppose your organization does work with external QA. In that case, it’s a good idea to create a separate collection for them, where external QA Analysts can be added as either external members or guests.
Again, taking advantage of Favro automations, it’s possible to automatically add defects found by external QA to the internal QA bug backlog.
Sometimes integration with legacy tools such as Jira is unavoidable. In these cases, Favro has a native, two-way Jira integration. Bugs entered in Jira will automatically be added to a Favro board and vice versa. The bug cards’ movement from status to status can also be synchronized between a Jira board and a Favro board, along with assignments and resolutions.
Every development organization has its unique way of tracking and resolving bugs. Favro’s flexibility makes it possible to map any existing bug flow to the app, maybe starting with an integration to a current bug tracking system and migrating over time.
Regardless of your unique way of working, the focus should be on detecting defects and resolving them as early as possible. As we’ve discussed, this is best achieved by having all product development stages take place on the same platform. In the spirit of continuous improvement, your quality assurance processes will evolve. Again, Favro’s non-centralized, team-empowered design makes implementing these process improvements effortless, whether they happen in Product Management, Development, DevOps, or QA.
This video walks you through exactly how to set up Favro for QA.
.jpg)
