Scrum team starts working on stories part of current release but scheduled for upcoming sprint

Last post 06:22 pm June 30, 2020
by Steve Matthew
3 replies
Author
Messages
02:26 am June 30, 2020

Some Scrum teams in my organization start working on stories which are potentially part of the release, but not part of the current sprint.

1. Teams plan the next few sprints (at a high level) during each SAFe PI planning, so they have an understanding of what's coming in future (although it might change)

2. Only 1 member works on any story, with an exception of an automation test engineer. Peer reviews are done by a couple of senior members. Team and management are not convinced about the benefits of pair programming or mob programming. Team size is 7 + PO & SM.

3. Team completes planned stories for each Sprint

4. But on day 1 of each Sprint, few members start working on stories which are potentially part of the release, but not planned for current Sprint.

5. Members think that stories are small enough and don't need more than 1 person to work on each. And, don't think that all stories can be completed in the same sprint. So they decide to have few members work on current Sprint stories and junior or newer members work on stories in future sprints.

Are there any metrics or flow diagrams that can help the team visualize the problem? I am not able to articulate how to approach with the team that this is an issue in terms of sustainable pace, continuous flow and predictability.

05:30 am June 30, 2020

Some Scrum teams in my organization start working on stories which are potentially part of the release, but not part of the current sprint.

In Scrum, shouldn't the work completed every Sprint be potentially and immediately releasable?

You appear to be using a non-Scrum framework while using Scrum terms. This has confused the situation and reduced transparency. Scrum behaviors and outcomes cannot realistically be expected.

05:48 pm June 30, 2020

Ian Mitchell is right in that using Scrum terms but not using Scrum is confusing. The terms come with definitions and expectations that may not be met, which makes it hard to have a conversation that aligns with what you are actually doing.

However, a few things that you say do stand out:

  • I'm not convinced of the value of any kind of long-term planning, whether that's "quarterly planning" or SAFe's "Program Increment (PI) Planning" or anything that looks out more than a Sprint. Every iteration should have an inspect-and-adapt period which could cause your longer-term planning to be invalidated.
  • The idea that people work in silos and "senior" team members are the ones who review the work are antithetical to a self-organizing, cross-functional team of equals. Has the team actually experimented and given pair programming and mob programming a chance? Admittedly, it's not for everyone, but it does work for many teams. I'd also point out that reviews are a good way to learn, not just to find mistakes or errors. I've previously written about different reasons why you would want to carry out a code review.
  • There are inherent transparency issues with working on things out of the Sprint. Mainly, you don't know how long it has taken or how much effort has been spent. This makes it hard to determine capacity and give any kind of reasonable forecast. Overall, this would harm empirical decision making.
  • People working on things that have not been selected for the Sprint seems to indicate a lack of focus and commitment to the current Sprint Goal. I believe that this is something worthy of discussing at a Sprint Retrospective to understand why the people who do this feel that it is appropriate.

I don't think the problems are around visualization, but focus, commitment, transparency, and empirical decision making.

06:22 pm June 30, 2020

Some Scrum teams in my organization start working on stories which are potentially part of the release, but not part of the current sprint.

But on day 1 of each Sprint, few members start working on stories which are potentially part of the release, but not planned for current Sprint.

 

@Jaysmika Patel, Why do they do that?

 

And, don't think that all stories can be completed in the same sprint.

 

Why? Do they have dependencies with other teams? If so, how can they minimize or eliminate those dependencies? How can they self-organize as multiple teams?

Are they using Sprint Goals every Sprint?

 

Also, since you mentioned SAFe, are all the Teams within your ART working on the same Product? or are they working on separate projects/initiatives?