Time box of sprint?
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.
How empowered are these so-called "resources" to decide, in collaboration with the PO, the best Sprint length for optimizing Product value?
What are the organization charges? And who advised to go to 2 weeks and why?
@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.
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.
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.
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.
Advantage:
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 !!
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.
[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
Prerequisite:
# Able to split the user stories to granular level deliver within 2 week cadence
Advantages:
# 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)
Thanks.