Managing release blockers with greater visibility

Streamlining Your Release Process: The BounceBack Approach for Improved QA and Release Management

When working at a previous startup, there became a point during our rapid iterations that stories were being marked as ready for QA without fully meeting acceptance criteria (AC). Work was being hurried past the finish line without ensuring it was prepared for testing.

It was disruptive to the QA team and a vast task switching cost to engineers when they would be handed back a story two days later. QA would try to test what they could, and some issues would get logged as bugs, but ultimately, the story wasn't complete and would sit in limbo. It would return to an In-Progress state and be re-assigned, or worse yet, return to To Do. This made it challenging to track completed work and was a headache come release time.

During release time, we'd have work checked into our release build that was due to be part of the sprint increment but needed to be completed, and we needed more visibility on its completeness within JIRA. Here is where the concept of a BounceBack column gave us clear visibility into work potentially blocking the release.

This, combined with bug tickets related to that release, allowed us to decide what was going out in that release very quickly and what needed a little extra push/polish. Thanks to feature flagging, we could turn off what's not done (as long as it wasn't causing other issues) and push our release out.

Anything left in the BounceBack column becomes the top priority for the team to clean up, even if it wasn't going to make it into the release; this was work that fell out of the previous sprint. Now, you can handle this by prioritizing the work in the sprint backlog, but this extra lane gave extra visibility to work without it blending in with the new work that sprint.

Since I started coaching, I've talked to numerous other PMs who have all had similar challenges at some point. I've shared my BackBounce approach with a few mentees over the years, and they've also seen great results. I want to share more about implementing this strategy; you could also benefit from this process change.

TL;DR: Add a new Kanban column called 'BounceBack,' have work that isn't complete get moved back there by QA and alert the developer immediately. We called ours the 'Bounce House'.

---

Goal

Reduce blatant errors and issues resulting from rushed work or lack of attention to acceptance criteria. We've all been there; sometimes, we need a nudge to get us back on track.

💡 Note: This could be a symptom of unrealistic deadlines or expectations. If that's the case, the solutions provided below will likely cause frustration with your team. Diagnose and deal with other root causes first.

How

Add a new column to your Kanban/Scrum board called 'BounceBack.' Have Product or QA move stories to this new column when acceptance criteria were missed or testing isn't possible and re-assign to the developer who closed the ticket. (if you're feeling clever, you can create an automation to re-assign tickets to the last assigned user, which is what we did).

When

The engineering team must complete tickets, meet all acceptance criteria (AC), or test their work before merging their pull request (PR). It is immediately apparent to QA that there is a misalignment, and QA should notify the developer immediately to reduce task-switching costs.

Why

Typical Kanban columns are: To Do, Doing, Done, and sometimes QA. However, what happens with work that doesn't pass QA? If it's a bug or regression, you could log a separate bug ticket to fix it. What if the work didn't meet the acceptance criteria (AC)? In practice, this might move back to the Doing column. The goal is initial visibility on where that item came from. The solution that worked for us was the BounceBack column. So, if you're having trouble managing release blockers and visibility of work, try it and let me know how it works.

---

Coming up Next

Roadmapping is something I often get asked about. It’s also something that takes on different forms depending on the company and your role. There are a lot of ideal roadmapping processes out there, but I often find they don’t live up to the scrutiny of the real world.

As part of a 7 part series of posts, I’m going to write about roadmapping; what it is, how to do it, and when to do it with real examples. This still won’t cover every scenario, but take form it what you can and if you’re in a unique situation, I’d love to talk specifics with you.

Through the next 7 posts, I’ll be breaking the concept of Roadmaps down into the following modules:

Part 1: A living document

Roadmaps aren’t intended to remain static. We’ll explore some ways to help keep your roadmap fluid and up-to-date as things change.

Part 2: Prioritization and planning process

How do you decide what gets put on your roadmap?

Part 3: Milestones

When should you add Milestones to your roadmap? What constitutes a milestone?

Part 4: Outcome-based roadmaps

This type of roadmap focuses on outcomes over features or solutions.

Part 5: Now, Next Later - Nov 28th

Avoid concrete timeframes and focus on priorities.

Part 6 Development Roadmap - Dec 5th

The roadmap you build for your dev team differs significantly from what you would create for your stakeholders and customers.

Part 7: Layering your roadmaps - Dec 12th

How layering shows different levels of detail within your roadmap for various stakeholders and taking a simple approach to maintaining them.

Let me know if there's anything else about roadmaps you want to see expanded on, and I'll develop this series more if there's enough interest.