Is it possible to do anything between two sprints, as there is no time gap ?

There is no time between sprints but things like changing the team composition should not be done in the same sprint. Basically, if you're going to change the team, wait for the sprint to end and then make the change so when they start the new sprint, they will be ready to go. In other words, if your sprint ends on Monday, have it so the dev team changes take place first thing on Tuesday.

That means everything we do in scrum is always within some sprint and actions like 'changing development team composition' etc. cannot be achieved between two sprints (but have to be done within sprint), at least in ideal scenario. Can someone point out what's wrong with this inference.

Why do you suspect that something may be wrong with that inference?

Is there a problem that you have experienced or foresee with back-to-back Sprints, each being a container for all other events?

@Curtis Thanks for your explanation.

@Ian, I don't see any issue with back to back sprint and the sprint being a container for other events. The inference stated in the post is as per my understanding after reading the Scrum Guide.

However, I came across the below question in a PSM 1 mock test. 

Q.When can the composition of the Development Team change?

The correct answer given is "Not during the Sprints" ; but as per my understanding the answer should have been "whenever needed" . The explanation given for the  answer is   "We don’t expect it to change often, but if required, it shouldn’t be during the Sprint". 

So I thought I was missing something while reading the Scrum Guide.

The Scrum Guide does not allow for time between Sprints.

Time that must be scheduled between the events at the end and start of a Sprint should be seen as waste. These gaps are lost opportunities to benefit from working towards a Sprint Goal, and so we should try to eradicate such waste.

However, in reality, there are often circumstances in many organizations that cause these gaps to appear. Often it's caused by things like having to book meeting rooms at certain times, variance in working hours of some team members, or being bulldozed off schedule by company-wide events.

In my opinion, Sprint Planning would be a very convenient time for changes to take place. This doesn't need to be formalized. It could simply be that it is already known to the team that Sharon and Timmy will join the team, and that they are invited to participate from the Sprint Planning onwards. One would hope that the team account for the effect of this change to the team, when setting a Sprint Goal, and forecasting what can be completed.

In any case, the more transparency that can be provided to the Scrum Team and its stakeholders about the changes, the better. For instance, if someone becomes available to join the team in a month's time, it would be good that the team know this early, so that they can plan accordingly.

Hi there,

i worked for about 20y. as a sysadmin for different companies - without scrum.

Actually I am transforming to a devop-engineer for another company which is working based on scrum. So it´s all new to me. After finishing some sprints my feelings tell me: that if there is no break, there will be a burnout. Not only for me. There is no time for taking a breath or do some non-sprint-related work (for example some rework of the past sprints, reply to tons of emails and service-tickets...)...

If there are new upcoming problems, etc. you have to squeeze it into the actual sprint...



There is no time for doing some learning new technologies or discussions of concepts or where to go in future. Its just like "Go Go go!".

Scrum seems to be very interesing and helpful, but without breaks between the sprints, it´s like burning down the people. Do you know any athlete who runs sprint by sprint by sprint without taking a recover-phase? I´m sure he will collapse..

Without scrum: after I finished a project I got the time to recover myself and do some "queued" tasks... I dont understand why scrum-master-authors cant get this in their mind and into there books. It´s all about people, not machines!

Thank you..... I have to hurry up for the next sprint - i have no time anymo...... 



 

Scrum, and agile in general, advocates a sustainable pace.  It sounds like your organization is not striving for that and are instead trying to account for every minute of an individuals work.  No where in any agile practice that I have read or experienced is there guidance to plan 40 hours of work for every person every week.  Some of the things you mentioned above very well into Scrum.  For example:

 do some non-sprint-related work (for example some rework of the past sprints, reply to tons of emails and service-tickets...)...

This is the opening statement for the section that describes the Product Backlog in the Scrum Guide. 

The Product Backlog is an ordered list of everything that is known to be needed in the product. It is the single source of requirements for any changes to be made to the product. The Product Owner is responsible for the Product Backlog, including its content, availability, and ordering.

Rework of past sprints is addressing technical debt that has been incurred in order to deliver value.  The Product Backlog should have items in it to represent this work as it is needed in order to keep the code base manageable in the long term.  Those items should be ordered accordingly based on the feedback from the Development Team. The Product Owner needs to be made aware of the needs for the rework, the impact of not doing the rework so that they can appropriately order it in the backlog.  The Product Owner is responsible for ensuring the Development Team is working on the correct items in order to deliver the most value.  In other words, these items can and should be introduced as "sprint work". 

Without scrum: after I finished a project I got the time to recover myself and do some "queued" tasks... I dont understand why scrum-master-authors cant get this in their mind and into there books. It´s all about people, not machines!

I have yet to read any material on scrum where it is advocated that only new features are worked on or that an individual should spend ALL of the time working on delivery of new features.  If you have an example, I'd like to see it for my own education. 

To your opening statement in the quote above I would say that you have not been working on projects at a sustainable pace.  If you have to ignore email, service-tickets and similar things to finish your projects you are missing out on delivering a lot of timely value.  No one likes to have their service ticket ignored or recieve a needed email response days later because the responder was ignoring the matter.  Yes context switching is bad but there are times it is necessary.  

The next Sprint may start only if it really makes sense to continue working, right? If for example, after the conclusion of Sprint 1, we need to wait in order to ascertain if what we released is truly valuable, then can't we start Sprint 2 as soon as we get that validation? In that context, would it be wrong to say that we started Sprint 2 immediately after the conclusion of Sprint 1? If that's not true, then can Scrum be a good candidate for work that falls in such a category? Just curious, and wanted to know what others think. Thanks.

We're starting a series of 'bridge sprints' to allow our dev team to decompress between, say, implementing a new public website and moving into a database migration. Complete change of workflow, scope and technology. 



It's hard to switch gears even with planning and backlog grooming beforehand. Benjamin, I can say that doing scrum for a little while and not liking it doesn't mean scrum or agile is the problem. There are a lot of factors in how your projects and handled. Is there a dedicated scrum master? Or a Product Owner? If it's a bunch of Project managers pushing you and your team forward, there is going to be friction.



And as said above, rework and bugs is technical debt and should go back into the backlog. Issues and known elements are not the only thing in a sprint. We have a whole section of Dev-Ops that are reactive during a sprint. We don't live in a world where you can perfectly pre-populate a sprint with the ONLY work that will be completed.



Making work visible is the purpose of agile and in the scrum method, all of these workstreams need to have equal weight in planning. If whoever is planning your sprints isn't taking this into considerations and expecting devs to "find time to do it" they aren't using scrum correctly. But great thing is, you're now in an agile team and an agile team should be able to talk about flaws, make changes and refine their process.

Question in Brief:



Let's say, we have 3 weeks Sprint. 



1. QA member may be anticipated to provide the Test cases beforehand to the Development Team member. And it's obvious that the Development member wants that beforehand to begin working on the task.

2. Let's say, Developer delivers the story at the end of the day on the last day of the Sprint. How can we anticipate the QA member shall be able to validate the task completed?

3. Technically if one process is followed by another in SDLC. How can the same deadline be applicable for all the process owners. 

Kindly share your views. Thanks in advance.