How I Revolutionized Our Sprint Completion with One Key Mindset Shift
A few sprints ago, I began to notice a pattern in our team’s delivery process. While we were seeing improvements in our sprint completion rate, there were still stories that consistently failed to cross the finish line. The root cause? Unforeseen testing blockers. I knew we had to make a change. I decided to push for a shift toward a “test-first” mindset, bringing testing into focus during refinement so we could plan ahead and avoid delays.
The Problem I Saw
One trend that stood out to me was how our burndown charts weren’t reflecting the steady, step-wise progress we expected from Agile Scrum. A lot of tickets were rolling over from sprint to sprint, and it became clear that undefined or lengthy testing strategies were often to blame.
Without clear testing strategies established early on, we kept encountering rushed, last-minute efforts that impacted both sprint completion and delivery timelines. I realized that if we could start planning for testing earlier, we’d have smoother sprints, fewer surprises, and ultimately deliver features more predictably.
My Objective
My goal was straightforward: I wanted us to define the testing strategy for each ticket before it even entered the sprint. While I didn’t aim to implement Test-Driven Development (TDD) right away, I saw this as the first step toward a future where we could adopt a “test-first” approach. My focus was on eliminating ambiguity, reducing the need for manual testing, and aligning our testing efforts with the overall sprint timeline. This mindset shift would set the foundation for a more test-driven development process down the road.
How I Led the Shift
- Defining Ticket Testing Types: I introduced a simple but effective system to categorize tickets based on their testing requirements. Each ticket was labeled as
Test_Strategy_Automation,Test_Strategy_Manual, orTest_Strategy_None. This helped everyone on the team quickly understand the testing approach—whether it would be automated, manual, or not needed (which was rare). While maintaining these labels wasn’t always straightforward, it was a low-effort way to start building a consistent testing approach that the whole team could easily follow. - Establishing SOPs for Golden Flows: One of the first steps I took was creating Standard Operating Procedures (SOPs) for manual testing of critical flows in our domain. These flows required consistent manual testing, so I made sure we had clear guidelines to follow. The idea was to minimize ambiguity around what needed to be tested, reducing the need for team members to create testing steps from scratch. While we aimed to cut down on manual testing, these SOPs provided structure when manual testing was necessary.
- Adjusting Our Refinement Process: I encouraged the team to start thinking about testing earlier in the refinement process. Over time, we became better at identifying test cases and incorporating them into the ticket details. During refinement sessions, we discussed which use cases needed testing and whether that testing would be manual or automated. For instance, when refining a pipeline modification ticket, we’d plan to automate the testing using unit tests, while manual testing might involve running the pipeline and verifying the results.
- Introducing Technical Deep Dive Meetings for Complex Stories: I recognized that some stories needed more time to discuss their testing strategies. When refinement sessions weren’t enough, I pushed for integrating these conversations in our weekly deep-dive meetings where we could explore edge cases, map out test scenarios, and even design interfaces together. This ensured that more complex stories received the attention they needed, particularly when it came to testing.
What This Process Looked Like:
- Refinement: We would select a ticket for refinement and ensure it was fully fleshed out in terms of functionality, user stories, and acceptance criteria.
- Testing Strategy: The next step was always to discuss the testing strategy. My goal was to ensure that we decided whether testing would be manual, automated, both, or — rarely — not required.
- Ownership: I made sure that the entire team shared responsibility for the testing strategy. This kept both the implementation and testing aligned, ensuring everyone had a thorough understanding of the ticket.
The Impact of the Shift
By introducing this “test-first” approach, I helped the team reduce the risk of last-minute testing surprises. Sprint completion became more predictable, and the overall efficiency of our delivery improved. High-priority features were delivered on time, and we experienced far fewer bottlenecks or delays due to testing. It was a significant change that helped us align better with Agile principles and made our sprints flow much more smoothly.
Moving Forward
If this is something that interest you, I suggest you take the charge and lead discussions on how your team could take this new approach and implement it across all upcoming stories. Review testing strategies, discuss immediate implementation, and keep the conversation open to continuous improvement.
This will just be the beginning, but it will lay the groundwork for future adoption of more advanced testing processes like TDD, and mark a clear shift toward a more testing-conscious culture in your team.
Make Peace with AI, it’s the new electricity. Happy Coding!
- Kandyce
