Simon is a hands-on software architect and has a BSc (Hons) in Computer Science from the University of Reading. Over the past 12 years, he’s been involved in projects ranging from rich desktop clients and web applications through to highly scalable distributed systems and service-oriented architectures; predominantly within the finance industry. He's also undertaken consulting and training roles with a broader focus on people, process and technology.
How long is a timebox?
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?
Re: How long is a timebox?
Re: How long is a timebox?
I just posted a couple articles about 1) Using timeboxes to schedule delivery and 2) Scheduling change requests.
The process identified in the scheduling post allows us to handle churn without affecting the ideal timebox duration. Scott Sehlhorst
Re: How long is a timebox?
I've had several long working experiences with iterations of a month, three weeks and one week. I've typically preferred the larger iterations.
Week-long iterations incur too much cost of overhead in managing the iteration -- what features are in, and out, branching, if necessary, and so forth.
Month-long iterations allow for a team to focus on the work at hand while still allowing for a rapid feedback cycle (at least, if the overall development process is at least three iterations long). For shorter projects, it seems like shorter iterations might be valuable.
