3

If your developers have completed their Sprint commitments (QA is ongoing - and any issues found by them are fixed in the same Sprint), what are the possible issues with developers picking up items from the Product Backlog to start working on (assuming QA will not be able to test them in this sprint?)

Is it OK to do, or are there any pitfalls of this approach?

Note: We have a Scrum-based release every 6 months today, but plan to move to a Kanban based approach with continuous production-deployment in the future.

Improve this question
2
  • 2
    Why do team members have individual commitments, rather than full-team ownership of the work?
    – Todd A. Jacobs ♦
    Commented Oct 17, 2019 at 18:26
  • Our teams are still divided into full time dev and qa structure and not everybody does everything at this point.
    – Mokshi Kalsotra
    Commented Oct 17, 2019 at 18:43

2 Answers 2

Reset to default
5

The first thing that I'd point out is that, in the most recent (November 2017) revision of the Scrum Guide, individuals do not have commitments. The team also does not commit to a body of work, but the accomplishment of a Sprint Goal that is established at the Sprint Planning.

With that in mind, if the team's Definition of Done is that work goes through the QA process, I'd ask why the developers are not assisting with the QA process to ensure that the work gets to a Done state within the Sprint.

I'd tend to caution the team against having too much work in progress - anything that is in some state of progress but doesn't meet the team's Definition of Done - can be wasteful. You run the risk of the work not getting to Done within the Sprint timebox and feedback (perhaps from the Sprint Review) invalidating the started work. Additionally, the context switching from the new, unplanned work back to older work can be time consuming.

Rather than starting new work, I'd rather the team focuses on the Sprint Goals and helping to get work to Done.

Improve this answer
2

One potential issue is it can put the Sprint Goal in jeopardy.

Presumably, if these stories were not included in the Sprint, then they aren't necessary to complete the Sprint Goal. Whereas the stories waiting to be QA'd may be.

In such a case, it would make more sense for your developers to focus on getting those stories Done as soon as possible. This may involve assisting the QA personnel in anything they may need, or possibly doing some of the QA work themselves - after all, having a Development Team consisting of T-shaped people is a worthwhile goal.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.