The Two Week Sprint

Agile, particularly scrum based agile, is focused around the “sprint”, a block of work that the team takes on to deliver for a segment of work.

Each team will define what a “sprint” is, and one of the beauties of scrum is that there is a lot of flexibility by design. A scrum team can define things like how to break things down, how to estimate the size of tasks, and what “done” with a task means.

As part of this documentation and defining how the team will work is healthy, and really great to watch in action. Part of the parameters defined is the duration of the “Sprint”.

In the way back time

I first was part of a team making the transition to scrum in 2009. We had a single team, colocated in Tucson, and I was embedded with the team. There were probably 20 engineers and QA people directly on the team, and we had a pair of scrum-masters, two lovely ladies who really could keep it all on track. (Oh, how I miss them)

There was no directive from above to make this transition, it was organic within the team, and everybody was fully engaged, and on board.

We had 3 week iterations or sprints, and at the turn of an iteration, we would do a full day of ceremonies, starting with the demonstration, the retrospective, and then we would eat lunch together, before we began the planning for the next iteration.

Heck, we were old school, and use 3x5” cards on a large cork board. That was fun, and yes, I wrote every user story on every card. Something tactile that was very comforting.

Our sprints were three weeks, and the thing that always astounded me was that 90 minutes of planning would eerily track with what the team could accomplish in three calendar weeks of work.

After the full day of ceremonies, I would take the entire team to the local watering hole and wold buy beer/drinks/appetizers for the team. Hugely recommended.

As I was both the product manager, as well as the product owner, this was a very workable scenario. I could spend 2/3rd’s of my time doing product management things, and then buckle down for the last week to groom and prepare the backlog for the team, write the user stories, and feel like I was giving the team what thy needed to be successful.

I loved this, and the team performed very well.

The Current State

Where I work now, we are moving into SAFe, and regardless of what you have heard about it, I am not here to promote or denigrate it, but it seems like the current best practice is a 2 week sprint, and that the longer sprints are rarities.

Honestly, I struggled with the transition, because it means that I needed to break down tasks into reasonable things to accomplish in 10 business days rather that fifteen business days.

But even more of a problem is if you as the product manager are also the product owner, and suddenly 1/2 of your time is spent doing the tactical duties required by the team, and clearly, the product management duties are curtailed.

Of course, for this to work, you can no longer be both the product owner and product manager, and fortunately the SAFe world (especially the consultants who handhold the roll out of the framework) strongly recommends dedicated product owners who are NOT the Product Manager.

I won’t go into the specific details of our deployment of SAFe, but during our last PI (program increment, the quarterly big planning activity) I asked bluntly why everyone is going to 2 week sprints. The answer was not surprising, but it was sort of what I expected.

It allows a fiscal quarter to be divided into 6 two-week sprints, and since once per PI, we have an “innovation” sprint, that takes two weeks, so that gives 5 sprints per PI. If we did three week sprints, we would have just 4 three week sprints, and if one of then was for the “innovation” that would mean just three per quarter.

So, in reality, it was a way to force Scrum agile to work within the corporate fiscal calendar, and mesh with other processes.

Why I am not a fan

I already mentioned that early, I was both the Product Manager and the Product Owner. That was chaotic, but a three week cadence and some cleverness in managing our backlog, this was do-able. In two weeks, it is unworkable.

Second, the two week sprint is constraining. Some tasks don’t break up that small, so we have LOTS of “Epics” that stretch across two or three iterations. I don’t like that, but the team seems OK with it.

Third, it is really shitty that corporate cadences, and processes intrude upon the team’s natural rhythms. All so that it can “map” to corporate processes and fit with functional leadership expectations.

I can understand it, but I don’t have to like it.

What say you?

What do you think about this?  For this post, I will turn on the comments, so let me know if I am reading too much into it, or is 2 weeks better than 3?