What is a Timebox, how does it work in Scrum and in conventional Project Management?
Timeboxing is a technique for scheduling projects, processes and activities. It defines a time frame and weights the time factor higher than the resources and content factors. In contrast to classical project management with the definition of work packages and the fixation of services to be performed, a timebox defines the duration and time frame for a job. In order to meet the specified time frame, contents and volumes can change in the course of a timebox. Processes are thus terminated after a defined duration at a defined point in time, even if not all planned contents of the process could be realised. Unimplemented content is moved to subsequent timeboxes or deleted if necessary on the basis of new findings. The great advantage of timeboxing is that it supports planning, even if companies operate in a dynamic environment and desired results cannot always be specified in advance and completely.
Differences to a Deadline
There are three main differences between a deadline and a timebox:
- A deadline is not set by a development team – i.e. from within an organisation – but mostly from outside, e.g. by a client.
- A deadline is a period of time during which a service must be provided by a fixed date, otherwise there is a risk of consequences. Timeboxing is an attempt to complete a large number of tasks within a given, jointly agreed timeframe without the risk of consequences.
- The mindset is different. When working with deadlines, the power lies with the client, when working with timeboxes in a team.
The Duration of a Timebox
The purpose of timeboxing is to set and limit times for projects, processes and activities. It is important to determine the duration of a timebox in a meaningful way. While too short periods can make the development of useful intermediate results more difficult, too long periods may increase the risk of undesirable developments with changing goals, requirements or boundary conditions. Here it is advisable to work together in a team to define a timebox that is suitable for the organisation, the working method and the project object.
meboxing in Agile Development
Timeboxing as a central Technique in Scrum
Timeboxing is a central technique in Scrum. It is part of the Sprint Planning as well as the Sprint itself, it is used in the Daily Scrums, the Sprint Review and the Sprint Retrospective. There are even organisations where timeboxing is used not only for sprints, but even within individual sprints, e.g. to eliminate ambiguities, to conduct research or when working with spike stories. An important thought in timeboxing is the clear Definition of Done, through which content that does not meet all acceptance and completion criteria will be handled in future timeboxes. In addition, working with timeboxing teams also encourages them to get down to work as quickly as possible, as this gives them early feedback and allows them to quickly adapt delivery items accordingly.
Timebox in Sprint Planning
Before a team can start development, it must plan it. This planning meeting is called Sprint Planning. The Scrum Guide recommends a timebox for sprint planning of 8 hours or less for a one-month sprint. The shorter the sprint, the shorter the time frame for sprint planning should be. For a one-week sprint, 2 hours or less would be appropriate.
Timebox during Sprint
The realisation of requirements takes place in Scrum during the sprints. In contrast to a classical iteration, sprints with a duration of one to a maximum of four weeks are very short. Which timebox is best for a company cannot be answered generally. When determining the timebox, companies can orient themselves on the planned total duration of the development, the corporate culture and/or the development object.
Timebox in Daily Scrum
Communication is very important in Scrum – not only between the stakeholders and the product owner, but also within the development team. That’s why developers come together at the beginning of a working day for a Daily Scrum. The Daily Scrum is a 15-minute timebox in which the team synchronises activities with each other, discusses obstacles to achieving goals and discusses upcoming tasks. Timeboxing is also used for the Scrum of Scrums.
Timebox in Sprint Review
At the end of a sprint, the developers demonstrate and discuss their results and check whether they have achieved their goals. Stakeholders also provide feedback. The product owner and development team then revise the product backlog. For one-month sprints, a timebox of 4 hours or less is recommended for a Sprint Review, a three-week sprint of 3 hours or less, and so on.
Timebox in Retrospective
At the end of the sprint, the development team conducts a retrospective under the moderation of the Scrum Master. The aim of the retrospective is to identify suggestions for improving cooperation in order to implement them in the next sprint. In a one-month sprint, 2 hours is usually suitable as a timebox.
Timebox in Backlog Refinement
The Backlog Refinement is not an officially defined part of Scrum, but the Scrum Guide suggests regular meetings between the Product Owner and the development team. Also the participation of the Scrum Master is recommended, because he can pay attention to the observance of the timebox. As an orientation for a timebox the Scrum Guide calls “no more than 10% of the capacity of the Development Team”.
Challenges for Companies
Timeboxing and conventional Project Planning
There are many companies that are active in regulated industries such as medical technology, pharmaceuticals, aerospace, transportation or the automotive industry. How can these companies reconcile timeboxing and classic project planning? There are several options. For example, classical work packages could be defined in such a way that their internal structures do not influence each other, because in this way work package A could be planned conventionally and work package B via timebox. Or companies could simply define milestones for intermediate results in a classic schedule, and the project manager would synchronise with development via product backlogs, release and sprint planning, and sprint reviews.
Here you will find additional information from our Smartpedia section: