Quality starts not from code. “Before Sprint” vs “In Sprint” delivery model

Shift left approach is very popular concept and approach when it comes to software delivery. According to wikipedia it “…is an approach to software testing and system testing in which testing is performed earlier in the lifecycle (i.e. moved left on the project timeline). It is the first half of the maxim “test early and often”…”.

It possess numerous advantages — early issue identification, cost savings, faster time to market, better risk management and many more others benefits. And it’s essential to emphasize one of the crucial criteria — gaining product knowledge and fostering close team collaboration right from the start. So where does the Quality start in this model?

Very often you may hear from the testing team “to test this feature I need latest code to be deployed”. However as a proactive leader you can facilitated a mindset change to work smarter and propose start testing right form the Story in the Backlog. Below you can find practically proven as efficient delivery model of “Before Sprint” vs “In Sprint” activities:

“Before Sprint” vs “In Sprint” delivery model

This model shows how to Start the Quality from the Story in the Backlog and establish efficient process to reduce time to market and illuminate risk of testing spillover to the next delivery cycle or risk to implement inaccurate requirements. If team works with high agility attitude the below “Before Sprint” activities can be easily adopted. Its just matter of proper planning what activities team is performing as part of the current Sprint as a contribution to the next Sprint— plan % of capacity that team will spend to prepare for the next Sprint in order to execute steps in the red box:

Quality starts from the Story in the Backlog

Story Quality is crucial for successful outcome. And as Quality Engineer you can proactively ensure adherence to the quality standards even before coding is started. The highest quality of the Story and adherence to “Definition of Ready” criteria the most accurate estimate team can provide during Sprint Planning, the better code will be written and the less number of defects will be reported and risk to implement inaccurate requirements can be illuminated.

So how to implement “Start Quality from the Story in the Backlog”? Here step by step plan:

Before Sprint activities to starts Quality process

1. Elaborate Story with the team and Product Owner.
2. Define Story Acceptance Criteria together so everyone on the same page.
3. Test INVEST. This is Story card assessment approach created by Bill Wake (wiki link to learn more). And very important here is to raise and document Requirements defects and make sure Root cause analysis is captured and noted. For some reason in most of the delivery approaches step of raising defects is described only as part of test execution. And mostly never mentioned as part of static requirements testing. Collecting defect metric before coding is a great way to measure return of investment and potential cost savings of preventing implementation of wrong requirements. Or if the Story criteria were incomplete that’s the straight risk to face missing requirements defects during business testing.
4. Write Acceptance Tests and link to the Story to make sure coverage and traceability matrix. One of the way to adopt this step is to include “Test Cases are defined and linked to the Story” into “Definition of Ready” criteria list. These acceptance tests might require the adjustments at the time of their execution. But the idea to have tests before Sprint starts is to indicate a full understanding of the scope to be delivered and volume of testing that will be required. Also team will know in advance what environment is needed and potential regression suite. Which is again “no open question before the Story is taken to the Sprint” leads to the most accurate estimate and the most accurate outcome of the delivery commitment. If your test strategy is to automate tests then applying ATDD (Acceptance Test Driven Development) approach is just perfect match in this case.
5. Estimate Story according to Baseline story point. It’s up to the team what classification of Baseline story point they will chose. In agile a Baseline story point is often used as a reference point to guide the size or complexity of other Stories in the Backlog. Teams assign story points (numerical values) to stories based on their perceived effort and complexity, with the baseline story acting as a point of comparison. This will provide normalized way to estimate what it takes for the team to deliver the smallest point (smallest independent scope of work). For example take the smallest Story that will take for about 60% of 1 day for Developer to implement, 30% of 1 day for Tester to validate and 10% of 1 day for Product Owner to review, at the end this baseline Story with estimate in one story point can be delivered within one day. Ideally breakdown of Stories should bring to the size recommendations that “Story should be small enough to be delivered within the Sprint and independent to be delivered per normalized Sprint burndown chart” (see table below with more recommendations).
6. Validate Story against “Definition of Ready” criteria list. This is again up to the team what they consider in this list. Here some example:

“Definition of Ready” criteria list:

• Story is prioritized in the backlog
• Story is estimated and matches team available capacity for the Sprint
• Functional requirements are clear and linked to business rules
• Non functional requirements are defined
• Technical details of implementation are documented
• Acceptance criteria are provided
• Dependent Stories are linked and resolved
• Test Cases are defined and linked to the Story (if you want to adopt “Before Sprint” activities model)
• All Requirement defects resolved and root cause documented (if you want to adopt “Before Sprint” activities model)
• Team knows how to demo the Story

Here few more general recommendations on the Story checklist:

Story decomposition guidance:

• The smaller the better
• Vertically sliced when applicable
• Breakdown can be done: by use case scenario or by happy / negative path or by workflow steps or by business rules or by data flow

Story description should represent multiple perspectives:

• Product Owner as business and user needs representative,
• Architect is advocating for technology stack, non functional requirements, security and environment cost management,
• Developer provides technical details of implementation and analysis of the selected tech stack to make sure no uncovered limitations,
• Tester provides broader input on acceptance tests including integration with other parts of the system, edge cases, hidden flows that may lead to requirements conflict.

Story estimation should include:

• Complexity — how difficult to implement and test.
• Current understanding of the system and technology.
• Unknowns — probability of facing uncertainty.

In summary, embracing shared responsibility and a team commitment to investing in high-quality user stories is the crucial of achieving excellence in the software delivery. This entails coding right requirements without redo effort, attaining comprehensive test coverage, and delivering outcomes that fulfills both user expectations and the demands of business needs. These principles are direct impact to customer satisfaction, improved team collaboration, and the sustained success of the projects.