Is it possible to suspend next spritn start for a while
Hi,
I have a question for you, as it is in the title. But maybe some prelude first.
Few days ago, I've talked with my friend about his project. He told me, that because of Xmas and some team members holidays, they decided to suspend next sprint start for new year. They have 2 weeks sprints. He also told me, that other way they can have 3 days spirnt (according to Xmas). They want to have full time sprint, so they'll start in the new year.
I told, that in my opinion they should start 3 days sprint, and plan less tasks.
Who had rigth in this case ?
How does the Scrum Team believe they can use the 3 days most effectively, considering the people and time available?
Frankly, I dont know - And probably it’s my mistake in this case. I’ve only based on scrum guide - next sprint starting immediately after previous sprint conclusions.
Hi Marcin -
If you follow the exact letter of Scrum, then the next sprint should start immediately after the last sprint ends. However, in most of the teams that I work with, the last week or so of 2017 provides a similar situation. Most teams have decided to delay the start of the next sprint until the first week of 2018.
We actually found, in this case, the delay allows a 2-week sprint schedule to better fit into the 2018 calendar. We use the time (about 3 days) for a version of "Fed Ex days" to allow Developers to work on a non-product independent project.
It's really going to come down to the trade-offs for your team. Skipping the "fuzzy" time at the end of the year does create more consistent sprints, but does go against Scrum guidance.
I think the more important thing is that if whatever your team decides to do this year doesn't work, don't try the same thing again next year.
What would be the harm in just saying this one sprint starts early and will be a 3 week sprint instead of the normal 2 week sprint? I would rather extend 1 sprint instead of creating a wholly separate 3 day sprint, but that's just me.
I also like what Brian pointed out, they could use these days for working on other issues that can be completed. As a scrum team, you want to provide a sense of value so if it comes down to the team does absolutely nothing for 3 days; what benefit is that to the organization and what value does that contribute? That's why I would go with the FedEx days like Brian mentioned or just start the next sprint early and have it run for 3 weeks, those dev team members that are in the office will work on what they can until after the new year when things are back to normal.
Hi,
thank you Brian and Curtis for your answers. Imust say, that all answers gave me a lot of tips. I must say, that Fed Ex days is something new for me (and for companies which I worked), but I've red about it, and sounds great :)
Option with 3 weeks sprint is the most satisfying for me. And I think, that it won't be against Ian answer :)
Again, thank you all for great answers.
You're welcome Marcin!
so if it comes down to the team does absolutely nothing for 3 days; what benefit is that to the organization and what value does that contribute?
I guess the real question there is, how much do you trust the team to be productive if they are allowed to select what they work on?
Mike Cohn came up with an interesting idea a while ago to schedule blocks of sprints for 12 weeks (6 2-week, 4 3-week, etc.), and then allow the 13th week to be a free week for whatever the team decided. They could work on tech debt, they could refine stories, they could spend the time learning or cross-training, the key is it would be left to them to decide.
This approach appealed to me because it fit into a corporate "quarterly" cycle, and that 13th week took care of issues like end-of year.
Timothy, That's a cool idea as well. My point was more targeted at IF (which is rarely the case) the team had no technical debt and there was work to be done that would provide value to the company. Typically, there is always work to be done but depending on the team and the company, there truly may not be anything for the dev team members to do.
Hi,
in the Scrum Guide is not written when the sprint planning has to start. My solution would be:
As long the Product Owner trusts the Developement team to work on some technical debt or improve their skills f.e. I don't see any problems with Fed Ex days, Trainings, etc during the Sprint. The Developement Team should make their results of course transparent.
So offically the lenght of the sprint would be three days and two weeks with a Sprint Planning after the three days.
Happy new year!
Nils
in the Scrum Guide is not written when the sprint planning has to start.
Nils, I believe the Scrum Guide is fairly explicit about when Sprint Planning must occur. If you read the guide closely, Sprint Planning is a precursor to the start of a sprint - basically, you cannot "sprint" without first completing Sprint Planning. Therefore, your proposed solution of conducting Sprint Planning 3 days into the sprint runs counter to Scrum.
Also, from The Scrum Guide:
Sprints have consistent durations throughout a development effort.
It not only runs counter to Scrum to introduce varying sprint lengths (i.e. - 2 weeks and 3 days), but it is wasteful from a Lean perspective (introducing variability).
If Sprint Planning happens 3 days into the Sprint, then there will be no Sprint Backlog for those 3 days. There will be reduced or no transparency over the amount of work that is thought to remain.
Transparency over the work performed by a team during a Sprint ought to be established immediately, irrespective of the nature of that work and whatever relationship it may have to product development.