Skip to main content

Time box of sprint?

Last post 02:04 am June 30, 2021 by VIJAYAKUMAR KARUNAMOORTHY
8 replies
11:21 pm June 25, 2021

Hello everyone 

My scrum team runs on a 3 weeks sprint timebox but recently due to some organisation changes its advised to us to change timebox from 3 to 2 weeks. 

Now here’s where a conflict begin

PO says that in 3 week box , approximately 24 PBIs were able to get delivered ( to note we have some shared resources who tests the final package)  whereas in 2 weeks box my dev team says that they won’t able to pull more then 10 PBI. So basically in a month release if i see for a 3 weeks 2 sprint we were delivering 48 pbi which will turn down to 30 for 3 sprints of 2 week ( hypothetically)

Po says that this should bot happen as this will effect deliverables and over all productivity  

Friends and dear mentor  how to deal with such situation. Looking forward for your suggestions.



03:16 am June 26, 2021

How empowered are these so-called "resources" to decide, in collaboration with the PO, the best Sprint length for optimizing Product value?

08:06 am June 26, 2021

What are the organization charges? And who advised to go to 2 weeks and  why?

12:48 pm June 26, 2021

@Ian:- These resources I am talking about are contractual resources however all forms a development team. These are actually Shared QA resources. Here the final package which gets created post 3 weeks is bound to be thoroughly tested by them. From Unit testing point of view, respective Dev those pull pbi on their name are already doing so.


@Sven:- These changes are some internal changes came from top management , also who advised to go to 2 weeks are our internal agile coaches. Reason behind is to stream line all application across firm to follow a standard & found this specific issue more related to change of mindset to adapt 2 week. However PO on other hand got his own point of  delivering less number of PBI if we go in 2 week sprint.  

10:03 pm June 26, 2021

Changing the Sprint duration isn't something that should be done lightly, but it may be necessary. What are the organizational changes that are driving the change from a 3-week Sprint to a 2-week Sprint? Who is making this decision and the team's involvement in understanding who wants this change, why, and making the final decision?

As far as the Product Owner's concerns, I believe that the Scrum Guide offers the answers. At Sprint Planning, "the Developers select items from the Product Backlog to include in the current Sprint." The Product Owner does not get to determine how many items should be selected. If the team believes that they should start by selecting only 10 items from the Product Backlog, that seems to be a reasonable decision. However, performance in the Sprint (along with continuous improvement through the Sprint Retrospective) can inform the team's selection of Product Backlog Items in future Sprint Planning sessions. Ideally, the team should have more than one Sprint's worth of work refined, so if the Product Owner is right and the Developers finish the work before the end of the Sprint, there are opportunities to take advantage of this slack time, which may include (but isn't limited to) pulling in additional work from the Product Backlog.

03:53 pm June 28, 2021

Po says that this should bot happen as this will effect deliverables and over all productivity  

It sounds like the PO has some valid points.  But what I don't understand is if they are disagreeing with the Developers or to the decision to switch from 3 week to 2 week Sprints.  

As for the change in number of Product Backlog Items that can be done, that also sounds reasonable.  But how of an change is needed is still to be determined.  Remember that empiricism will show the true answer.  You have to do something, inspect it and adapt.  Did the team start by pulling in 24 Product Backlog Items into the very first 3 week Sprint?  I'm going to be that isn't the case and over time they have come to that.  Also you said that "approximately 24 PBIs were able to get delivered ".   That indicates that the team is not always selecting 24 items and is sometimes selecting more or less than that number.  

As Scrum Master it is your responsibility to help the team understand the empirical nature of what they do.  Help the team agree to start with a number of Product Backlog Items in their first 2 week Sprint and then adjust as they learn more.  

By the way, I also would like to know what organisational changes are happening and who feels like they can dictate to the team what cadence they have to use.

04:22 am June 29, 2021

As long as you are able to split the user stories to a level you can able to deliver (design, build, unit test, SIT, UAT, release), and your PO know how to split the User story to granular level to complete within 2 weeks cadence, it is always possible to move to 2 week cadence. 

As long as you do capacity planning and plan for 80% in each sprint you can able to achieve the 2 week cadence.


Assume your PO want to release after every sprint.

If you take total 6 weeks, for 3 weeks cadence : 2 releases and for 2 weeks cadence : 3 releases !!

07:47 am June 29, 2021

How rigid is that "use 2 week sprints" enforced?

I wonder that noone so far mentioned that the Scrum Team should be self-organizing. The self-organizing includes sprint length in my opinion.

If my management would try to have my team change sprint length, tools we use or anything else that the Scrum Team is working with and acustomed to, I would tell management about self organization and that we will discuss it within the Scrum Team at the next Retrospective. I would leave the decision to the Scrum Team and if they don't see a value and want to remain with how they are working, inform the management about their decision.


02:04 am June 30, 2021

[1] if a team is able to do 3 week cadence (sprint length), then doing in 2 week cadence (sprint length) is doable.

[2] Nowadays agile coaches in the organization recommend to scrum teams to go for 2 week cadence if they are in 3 week cadence


# Able to split the user stories to granular level deliver within 2 week cadence


# Releasable products in more frequency

# Track the progress of overall product vision

# Align multiple scrum teams (if there are few tribes and many scrum teams in each tribe - scaling agile)


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.