Effects of a Time Box

When stories are big relative to the size of an iteration, the time box itself has a huge effect on skewing priorities of the work being done, or hiding work in progress.  The bigger the stories (relatively), the more pronounced the effect.

Suppose I have a large story that consumes 60% of the capacity of my sprint.  Assuming that the work is divisible enough across multiple developers, then this work with 'fit' in the sprint.  But now, having 40% of my capacity remaining, if the 2nd priority story is also large, it will not fit in the sprint, so I proceed down the backlog looking for smaller sized work, even though it's lower priority.  If we extend the time box, so that it is larger relative to the size of the work items, we can more easily work the backlog of items in priority order.    Depending on the relative business value of items in the backlog, not working on the most important items, could be a really bad side effect.

The other common 'fix' I have seen is in breaking down the work into smaller pieces.  There may be ways to break down work into smaller useful deliverables, and these should be explored first.  But often, the work is either just not divisible while still being useful, or the team just can't come up with a vertical breakdown of the work.  On a current project, the work is 'finished', but reliant on temporary scaffolding.

Now, after having worked several sprints, several features are in this scaffolded state, and the application as a whole isn't shippable.  The remaining integration work, and discovering the functionality that doesn't actually work is delayed and invisible.   Until all of the partially done work is either stripped out or completed, nothing can be released.  Basically, the team is now bound by this remaining scope that must be dealt with.  The timeline can't be frozen anymore since scope can't be variable.

Having gone off the 'staying releasable' path before... my way back to sprints was to just do a scope bound iteration to get everything integrated and working, and then go back to sprinting.  The team not being fully utilitized during this effort can be a scary thing, but adding more work just makes closing the gaps take longer.  And if the new work is dependent on an assumption that the old work is functioning properly or won't require drastic changes, it could just be one more thing that gets in the way.  My Scrum Master suggested any one not working on integration go play basketball... or just go home.   Playing ball at work would cost us less.

Getting back to being deliverable has to be the priority.  That doesn't mean you stop planning, but you just plan on demand instead of in iterations... pulling the next pieces of work when you finish up your current work.  Kanban mode.  At least until you can put the pieces back together again.  Depending on the pain you've built up, getting back on track can take a while.  But no matter how long it takes... putting the train back on the rails has to be the priority.  After we worked through the pain, our releases were always short and consistent.  But at that point, we were iterating on working software.