I came across this tweet by Karen Greeves.

Scrum Master fail… Improvement action: Bigger stories where only few members can participate should be scheduled to run over 2 sprints.

After a quick twitter conversation, Karen explained.

It removes the ability to measure progress via working software at the end of the sprint

My response was

Working software is not the only way to measure progress in a sprint. And what if it works? I think it can.

It may well not be the ScrumMaster that failed when it was decided to have a bulkier story span two sprints.  I appreciate that it is a whole lot better when a story is in one sprint, and that should be our default objective.  However, it’s often not so trivial.  Given that I don’t have a lot of context, I will be assuming a lot.

In this case, it is more likely a failure of the team that they (a) accept a story to develop over 2 sprints, or (b) was unable to do enough analysis to consider what can be done in one sprint.  It can also be a failure on the product owner for not entering into a meaningful conversation on the details of the story, and then, again, a team failure on not engaging the PO significantly to take the problem forward.

If I encounter a story that spans two sprints, and that is more often than you think (often discovered mid-sprint), then I’m not interested in working software but seek clarity of understanding in that sprint.  The outcome at the end of the immediate sprint is an unambiguous story (or maybe several stories) which is a statement of the problem domain, or even better, the solution domain.  That is what I mean by working software is not the only measure of progress in a story.  It is more important to “measure” increased understanding in each sprint, and good statements in the solution domain is at the heart of knowledge crunching.

The most neglected aspect of working software is a measure of understanding of the solution domain.  In my experience, many teams are great at expressing the problem domain in software and their code reflects the analysis of the problem.  Consequently, the code does not reflect the understanding of the solution.  The end result is a weak design.  Over many sprints that require work in the vicinity of the weak design, there will be a degradation in velocity because the code is just baking in the problem statement, and not a well crafted solution to the problem.

Next, let me deal with the case of just a few team members participate and not the entire team.  I think that is completely feasible approach.  I’ve done it many times to great effect and with great efficiency because the conversation is a lot more direct and contained.  It is later that the distilled knowledge is shared with the team.  This is largely crunching in the problem domain with some rough models in the solution domain.  When I’ve included the entire team in the analysis, then the effect is one of dilution and inefficiency – too many people over a longer period.

Lastly, I asked “What if it works?”.  While this may seem to be brash or provocative  question, it is meant literally.  What if it really does work? Hey, then what we’ve achieved as an odd case of delivery over two sprints instead of one.  If it happens often enough, then we need to adapt accordingly: increase sprint duration, have people dedicated to analysis (oops, bite me ‘cos I’m creating a silo) and maybe more if we just think a bit about it.

So, in my opinion, it is absolutely OK to attempt the proposed solution because it is an admittance of ignorance, but if the team does not understand the actual situation they’re in, then it is the failure of the team not the ScrumMaster.  I also think that we should understand the rules of the game a lot more deeply.  Like I’ve said in the past:

It’s not the rules that matter, it’s what we do with the rules that counts.

To each their own, and life goes on.