Jacqueline: Our letter for today is T, and our agile word for today is timeboxed. Timeboxing is what it sounds like: putting time in a box. Basically, it is defining a very discreet block of time to complete an activity. In agile, our goal is to timebox our work into small, discreet components. We call them either iterations or sprints. The goal of the timebox is to take a big problem, break it down into smaller components, deliver those incrementally and then get feedback at the end of each one of those timeboxes.
The typical time box can range anywhere from one to four weeks, and this is highly recommended. In my real-world experience, the majority of people use two-week sprints. Some go as far as three or four, and I have worked on projects as small as one week. But, what I want to share with you on this episode is the pros and cons of each one of those. Here’s a clear example when people hear and identify a certain ceremony with agile, but not necessarily understanding its intent, purpose or origin. They follow the lead without necessarily the same justification of its original intent.
Ultimately, the reason why, in agile, we want to do small sprints is to, by and large, avoid interruptions. We look to the product owner to decide the top priorities for the next two weeks. Let’s say that planning process starts on a Friday. Once everyone locks down and agrees to it, the team is not to be interrupted with new work, not even exploratory work when someone just wants you to look into something for them or a new story comes up and they want you to rough out the estimate, which takes research. All of those are distractions. Unless the sprint has time allocated for things like grooming, the only thing that is done during the sprint is those things agreed to at the release and the sprint planning.
If the product owner prioritizes their items on a Friday and the team starts working on it on a Monday, let’s say be Wednesday they discover something else that they really need. Now, the goal is to, as much as possible, get them to defer the end of the sprint, so an additional 10 days or so if we’re on Wednesday when the new request comes up. Can they wait another seven or eight days until the end of the sprint? If so, that’s successful in the eyes of agile, because what we did was not disturb the work in progress or the high-priority items that were determined just that past Friday.
We’re able to complete those as planned and then give this new item the due attention and the due diligence to research, determine the level of effort, do any type of coordination, and then make it the top priority and the new sprint versus being rushed in. This often happens in the traditional way we approach software development, especially with waterfall, because releases were often many months away before they were going to be released. So, when that emergency came up on Wednesday and we’re looking at the next release not being for three, four, five, six months, of course the product owner made enough noise that the team had to find a way to interrupt whatever they were doing to put that fix in.
But, here’s the issue: in the course of six months between releases, there are a lot of little emergencies that come up. Before you know it, everything’s a little emergency and everything’s being interrupted. So you get to the six-month mark and half of the stuff that you thought was going to be released got pushed out. This led to another frustration with product owners. So, the small sprint is so that we can protect that time and not have emergency interruptions. If there are emergency interruptions, we welcome and embrace change but not to the point it will be scheduled at the top of the list should the product owner desire at the following sprint. Ambitiously, it was the intention to deliver with every sprint.
Now, that can get to be a lot, especially if we’re talking about every two weeks or every four weeks, but I daresay, you might be surprised. There are some major installations that push out releases every week or every two weeks. Take your phone, for example. Sometimes you may know about it and sometimes you don’t, but someone is pushing a release to your phone multiple times across the course of a month. That said, one week sprints can be very stressful on a team. That means you’re doing your planning, you’re trying to keep up with your grooming, you want to make sure that your stories are in a ready state, you review them from planning, you do the work, at the end of the week you do a demo and a retrospect, and then it’s time to start planning all over again. Quite obviously you can quickly stress out a team and burn out a team.
Furthermore, if you’re going at these fast-paced sprints, then the next question I would ask is are you able to release every week. If you’re not releasing every week, is there real value in pushing a team to that level when it may still be four or five sprints before you’re ever releasing anything. Now, three sprints and four sprints are great and give the team a lot of lead way, but they can start to fill a little waterfallish, because the product owner gives their priorities. They go through those three to four weeks that really, again, is that protected time that they’re not to introduce any emergencies or urban fixes. In some environments and in some industries, for example, the hospital or banking industry, four or five weeks can be a very long time. The team needs to look at their inventory, the team make-up, and the team capacity. What’s the healthy and best timebox for their releases.
Keep in mind that it’s to help keep that time during the sprint or iteration protected, but at the same time, give the product owner some lead way so that when emergencies come up, they would have a commitment of no more than two weeks before a new start and no more than two weeks before that item would be completed. That is how timeboxing works in agile and some of the key points worth considering to determine the right timebox for you. I want to share a great resource that elaborates much more on timeboxing: http://www.telerik.com/blogs/the-importance-of-timeboxing-and-iterations-for-agile-planning.