Should a dev team work in a 2 week sprint if they have deployments every 2 weeks?

Why do you believe that your "Sprints" are one week long, when you don't plan to release increments within this time-box?

It's not clear to me why you believe that moving to 2-week Sprints will improve your ability to get work Done when you are unable to with 1-week Sprints. I'm not sure which Sprint duration is better to promote synchronization with stakeholders and realignment with the changing environment, but that should be the primary concern.

Although if your team is highly interrupt-driven, I'm not sure if Scrum is appropriate. It's one thing to have things come up to interrupt the team, but it's another to have a significant volume of interrupts. When you are interrupt-driven, it seems like attempting to plan a Sprint (whether it's 1-week or 2-weeks long) would be wasteful and a more continuous  flow may be more suitable.

One week Sprints are my preferred duration. However, I have done two releases to production in a single week. Efficiency has to do with how quickly your team can produce quality, releasable increments. I would discourage you from moving to two week Sprint because it could make the Scrum Team members complacent.

I have found that when a Development Team are expected to deal with a lot of unplanned work, it can be helpful to simplify that decision making process through agreements.

For instance, where I work, the Development Teams have made agreements around bugs and work to configure our product per customer. They also agreed on criteria that determines whether work is prioritized as critical, important, or normal.

For critical priority, this is treated as an interrupt, where other work is expected to stop, and focus should immediately shift to this. It's very disruptive, but only used rarely.

For important and normal priority items, validation of the request should take place within one working day, and a start date agreed, depending on the priority, and the judgement of the Development Team.

Having the discussion around such agreements can help Development Teams better understand what unplanned work is valuable, and what isn't. Furthermore it provides structure, and makes the interruptions more predictable and a lot more transparent.

For Sprint Planning, the Development Team has visibility about which items it has already agreed to start within the current sprint, and it can see how much planned and unplanned work it usually completes per sprint.

This allows the team to make a more realistic forecast, whilst taking into account the inherent uncertainty of having this stream of work.

@Thomas Owens

Thank you for your feedback! The team has never worked in a 2 week sprint before and the hope is that if we move to a 2 week sprint, there wouldn't be as much roll over of work. I can't say for sure if that will actually happen without trying it first. 

I too am not sure which sprint duration is the best for us since we work in a changing environment (E-commerce). 

If Scrum isn't the approach, what should the approach be? We're trying to be agile as much as possible. 

@Simon Mayer

Thanks for the feedback! We have something similar where we have an Urgent Urgent status for a story in Jira and the standard high, medium, and low. This is a drop everything you're doing and fix it asap. They don't occur every week but we have a status in place for it. 

I like your perspective on actually analyzing what urgent work is actually valuable. Currently, if something is urgent it's coming from senior leadership and in that sense is viewed as valuable. 

In terms of Sprint Planning, we don't have a formal meeting, which is an area of opportunity for us. The concern is devs will spend too much time on such meetings rather than actual dev work. It would be nice to analyze how much work is planned vs unplanned. 

The team has never worked in a 2 week sprint before and the hope is that if we move to a 2 week sprint, there wouldn't be as much roll over of work. I can't say for sure if that will actually happen without trying it first. 

I too am not sure which sprint duration is the best for us since we work in a changing environment (E-commerce). 

If Scrum isn't the approach, what should the approach be? We're trying to be agile as much as possible. 

From what you describe, I'm not sure that reducing the Sprint duration will greatly impact rollover work. It may be worth trying for a while to see, but it sounds like the problem is ad-hoc work coming in.

Scrum is good for a changing environment. Many of the agile methods are. However, many also operate on a planning cadence. Using Scrum as an example, if you cannot meet as a team for up to 8 hours to plan the next 1-4 weeks out with some level of certainty, that planning is wasteful. Yes, things do come up that require replanning to various degrees, but Scrum is effective when you can generally hold most of your Sprint plans most of the time. If your goals and workload are changing within a Sprint, you will end up canceling a Sprint. The Scrum Guide calls Sprint cancellation "traumatic".

If you are truly interrupt-driven, I'd look at more just-in-time processes. There's a lot to learn from Kanban. However, one problem that I've seen in just-in-time processes is insufficient time given for just-in-time planning, alignment on goals, and retrospectives. It's easy for an undisciplined team or organization to slip into a mentality of cranking out work items without keeping their eye on the big picture and finding time for improvement.

I too am not sure which sprint duration is the best for us since we work in a changing environment (E-commerce).

Scrum is about working in a changing environment. Any company that can not demonstrate agility in today's changing world will have difficulty being successful.  Only the individual teams can determine what the best sprint duration will be for them.  As with all things, it might take an experiment to discover the right answer.  

Your statements of being interrupt driven shouldn't have much impact on your Sprint duration if you account for that in your Sprint Planning.  However, as @Thomas Owens mentions, if your work is more interrupt driven than planned, you might want to consider some alternative practices.  You can still use some of the Scrum framework but realize that you won't be doing Scrum. You can be agile by using a combination of practices and methods. Some of those may not be described as part of any framework, practice, or methodology.  My advise is to experiment with what the team feels makes sense.  Learn from the experiment and always continue to adapt based on what you learn.