Develop user stories in the previous sprint, if sprint commitments met?



  • 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.



  • 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.


Log in to reply
 

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2