Forums

One of the assesment questions is about the reasoning behind choosing longer sprint length. I'm not going to post the question here in its entirety for obvious reasons, but I'll try to word it another way.


The question ask about a *cardinal reason* to choose said longer sprint length over a fourteen days sprint, because the amount of work is too much to be divided into units smaller than two weeks.


I do not understand the wording here. AFAIK Sprint's length should be choosen in accordance to:
a) acceptable planning horizon
b) time needed to produce increment of perceivable value
c) deployment overhead in some environments (i.e. embedded systems)
d) perceivable risk
e) not exceeding 1 month timebox.


but the question ask that divide of work is not possible for a sprint shorter than two weeks and whether it could be a good reason.


My answer would be No, because I'd try harder to decompose the PBI, but is it a right answer? What's your opinion on this?

Agree with your answer "No". Size of PBI shouldn't be a factor for choosing Sprint more than 2 weeks durations.

Within software development I have never found it very difficult to decompose PBI's to a size of a couple of days. So no reason to extend Sprints for that reason. PBI's of more than 2 weeks also are a high risk even for one month Sprints.

Reality in other industries might prove me wrong however ;-)

Well, Scrum is about delivering potentially shippable Increments. So Sprint length is best chosen to serve that purpose. How long can a team work in the splendid isolation of a Sprint container without delivering something to the market, at least show something to stakeholders.
And the, with regards to PBI size, Scrum has no more rules than that one PBI should be do-able in one Sprint. For shorter Sprint that puts the max size lower, that's all. In general it is better that a team can do more PBIs in one Sprint.

If it really IS impossible to break one (or even most) of the PBIs down to a size that fits a 2 week sprint, then there really is no other choice than to choose longer sprint length.

I agree that it is quite uncommen that this is the case, but I can easily imagine situations where this IS the case, for instance:
The company has QA policies that require this and that to be performed on any piece of code being released, or
The product has certain facets, that require expert knowledge to test, or
The software needs to be tested against "live" integration points that are not readily available

Each of the above points would warrant an extension of the Definition of Done for the team, and each of them might make it impossible to get even a single PBI done in a 2 week sprint.
I know the above points should be addressed, for instance as impediments, but solving them might be something that takes a logn time, depending on the company.

My point is: It may not be, that too much functionality has been lumped into one PBI, it may just as well be the Definition of Done, that prevents a sprint of 2 weeks or less.

Just my 5 cents :-)

Kindest regards, Mikkel