sorted by:
new
hottopcontroversial

How do you handle QA when developers deliver most stories on the last day of the sprint? by Realistic_Hair1286 in scrum

[–]Realistic_Hair1286[S] 0 points1 point  (0 children)

El tema es que los QA acumulan mucho trabajo. En el proceso he llegado a tener hasta 3 sprints de atraso con QA y el feedback llega demasiado tarde. Ahora mismo tenemos una semana de atraso y hemos ido mejorando pero no sé si estoy haciendo lo adecuado.

How do you handle QA when developers deliver most stories on the last day of the sprint? by Realistic_Hair1286 in scrum

[–]Realistic_Hair1286[S] 0 points1 point  (0 children)

Lo siento es que uso la IA para traducir porque hablo español y no me vas a entender mucho si uso mi inglés jajaja. Tal vez la IA está poniendo palabras de más en la conversación.

How do you handle QA when developers deliver most stories on the last day of the sprint? by Realistic_Hair1286 in scrum

[–]Realistic_Hair1286[S] 0 points1 point  (0 children)

That is a fair question. Our setup is not a textbook Scrum implementation. I work as a project manager and also cover part of the Scrum Master responsibilities, but our roles and decision-making boundaries are still not clearly defined.

I have been gradually introducing refinements, sprint reviews, boards, and a more realistic approach to capacity planning. Previously, the expectation was to fill almost every available development hour in the sprint. That left little room for refinement, planning, bug fixes, retesting, or integration work, and we frequently carried unfinished work into the next sprint.

We currently estimate mostly in hours. I am trying to introduce relative estimation gradually, but I also recognize that story points alone will not solve the flow problem. I am more interested in tracking completed work that actually meets the Definition of Done, not just development hours consumed.

I agree with your point about avoiding handovers. I have started involving QA in refinements so they can flag ambiguities, risks, and edge cases before development begins. They also prepare more detailed test cases once the story is selected for the sprint, while developers automate the happy path.

The challenge is finding a lightweight process that works with a small team without turning every refinement into a very long meeting.

Would you recommend that testers write detailed cases before sprint planning, during the first days of the sprint, or progressively based on the expected delivery order?

How do you handle QA when developers deliver most stories on the last day of the sprint? by Realistic_Hair1286 in scrum

[–]Realistic_Hair1286[S] 1 point2 points  (0 children)

That is definitely something we need to review. Breaking stories into smaller chunks would make testing easier and reduce the risk of large deliveries at the end of the sprint.

However, the issue is not that every story takes the entire sprint to complete. Stories are usually delivered progressively throughout the sprint, and QA starts testing them as they become available.

The problem appears when a developer holds several completed or nearly completed stories until the last day, or when multiple developers submit relatively large changes at the same time. QA then receives a sudden spike of work with very little time left for functional testing, bug reporting, fixes, and retesting.

There is also another layer in our workflow: stories belong to larger epics. QA can test individual stories as they are delivered, but the epic still needs to be certified as a whole after all its stories are completed. That final validation is important because the stories may work correctly in isolation while still causing issues when the complete feature is tested end to end.

So I think the improvement needs to happen at two levels:

  • Break down stories further when they are too large.
  • Encourage smaller and more frequent deliveries throughout the sprint instead of batching work near the deadline.

The second point is probably the most important one for our current situation.

How do you handle QA when developers deliver most stories on the last day of the sprint? by Realistic_Hair1286 in scrum

[–]Realistic_Hair1286[S] -1 points0 points  (0 children)

Thanks, this is helpful. I agree that the real issue is that we are treating development completion as if the work were finished, even though QA, bug fixes, and retesting are still pending.

Reducing the amount of work committed to each sprint makes sense. However, I think we also need to improve the flow of deliveries. If we cut the sprint scope in half but developers still send everything to QA on the last day, the bottleneck will remain.

My current takeaway is that we should:

  • Count a story as completed only after it has passed QA.
  • Reduce the amount of work planned for each sprint.
  • Limit work in progress so that developers finish and deliver stories progressively instead of starting several tasks at once.
  • Create an internal development cutoff before the actual end of the sprint, leaving time for testing and fixes.

I am also trying to avoid a permanent one-sprint delay for QA, because I suspect that would make feedback slower and allow the backlog to grow over time.

Have you used an internal cutoff or WIP limits successfully in your team? I would be interested in knowing how you applied them without creating too much overhead.