One of the most common questions about timeboxing relates to the length of timeboxes. How long should they be and what factors influence this decision?

While there are many recommendations out there, some of which are strongly tied to the development process you've adopted (e.g. Scrum recommends a month), the factor I would like to talk about is the skill of the team. Or rather, how much relevant experience they have. By relevant experience, I mean experience with whichever development process, team structure, technologies, tools, etc that are in use on the project. Based upon this information, you should be in a good position to find the ideal length of timebox that suits your project.

For very experienced teams, a short duration (say 2 weeks) allows for some very aggressive timescales and some very quick feedback loops, assuming that you would plan to do a release at the end of each timebox. On the other hand, a longer duration (say 4-6 weeks) is more suited to projects that are larger, more architecturally challenging or where the team is on a steep learning curve with the process, technologies, tools, etc. From experience, problems arise when you put a team that's on a steep learning curve into very short timeboxes and expect them to deliver. It's just not realistic to expect them to take onboard lots of new technologies *and* expect them to deliver something that's production quality.

The ideal length of a timebox for any particular project will vary and deserves some careful thought. Of course, adopting an iterative approach means that you have the flexibility to tweak the timebox duration throughout the project based on your growing experience.

Here at The Pragmatic Architect, we're interested to see what you you have to say. What are experiences here? What timebox duration works for you and why?

Read more...