ScrumBut – Part 1 – Timeboxed Iterations

Perhaps the very first and most widely “adapted” practice in the Scrum world is that of the timeboxed iteration. Henrik’s Scrum Checklist identifies four subareas of concern:

• Iteration Length 4 weeks or less
• Always end on time
• Team not disrupted or controlled by outsiders
• Team usually delivers what they committed to

The original guidance in Scrum was 30 day sprints, but current versions of the Scrum Guide now recommend teams start out at two week sprints. However, even this isn’t enough for some teams – while some struggle to achieve working software in 6 or 8 weeks, others release working software every day. So how does a team know when to modify timeboxed iterations?

Here lie dragons

It is perhaps easier to start with the antipattern of modifying timeboxes. Unfortunately, these are pretty easy to spot – the team fails to meet their commitment during the scheduled timebox. This causes spillover into the planning game and to the next iteration with the team signing up for even more than they did the first iteration.

This usually continues for several iterations until either the iterations are “extended” (“This iteration is now 6 weeks long”), made longer (“We can’t do 4 week iterations, so let’s make them 8 weeks long”), or dropped all together. At this point the team is now without any guidance at all as to when things are going to be done. Long term release planning now becomes a complete guess as the team’s velocity is wholly unknown, and typically the entire premise on which agile was introduced becomes unravelled.

Perhaps surprisingly, timeboxed iterations are not to blame here. Indeed, it is the lack of self-reflection from the team – often based on immaturity as a working unit – which led them to spiral into a pit of disrepair. Let’s look at the team making two different decisions to alter timeboxed iterations which result in a much happier outcome.

If it doesn’t fit, it’s too big

Let’s say the team encounters the end of their first four-week sprint and finds that they did not make their commitment. And they over commit the second sprint signing up for more than they had in their first sprint plus the additional overwork to be done. By the third sprint, they seem hopelessly destine to be another agile failure. However, the team members, recognizing a bad thing happening, quickly gather the team. They decided on the tactic that if you can’t finish stories during a sprint – your sprint is too long. They decide to see what happens when they drop to 2-week sprints.

They discover that they need to break their stories down more, become more targeted in how they test, how they develop, how they release. Suddenly, what they couldn’t do in 6 weeks, they are regularly making happen in 2 weeks.

Or perhaps it doesn’t belong at all

Let’s look back at our team again. They are hopelessly stuck on their third sprint. However, instead of shortening the iterations, they decide to find out what is causing them not to meet their commitments. They discover that while the work flows through development just fine, it gets hung up during testing.

To solve this, the team decides to establish a Kanban board to visualize the workflow state of the work in progress. Additionally, because of the amount of items caught in testing, they decide to put a Work-in-Progress limit of 4 on the test column. That means that if there are 4 items in testing, no others can be moved to testing until the items are cleared. So the developers can’t move things along, encouraging them to jump in and help clear the backlog.

After several iterations of this, with the team applying the theory of constraints to find impediments, they discover that the “timebox” concept for flowing work doesn’t fit with their model. They have become so adept at it that each story is now approximately the same size, so estimation becomes a simple act of card counting.

Which team are you?

You’ll notice that the key outcome here is dependent on two factors. First – the maturity of the team and their ability to self-reflect to look for solutions (and try new ones). Second – the context of the work coming in. For our last team, if the business couldn’t feed stories into the pipeline that were about the same size, then other tactics might have to be put into place to allow for estimation and sizing.

So when you are considering dropping timeboxed iterations, ask yourself – are we dropping them because they aren’t of value? Or because we are afraid to face the real issues causing us from delivering value to our customers?