What are Time-Boxed Meetings and how are they applied within Scrum Projects? Instinctively, when we hear that a Project or activity is “Time-Boxed”, we think of rigidity. With Time-Boxing, one of the most important factors in any Project is Fixed. There is no leeway to ask for extra time to finish what we set out to do. We have less room to manoeuvre. If the Project is following the Scrum framework, we cannot call on additional Developers to add to the Team. The Scrum Team size is fixed from the very first Sprint. So we are even more Limited as to what can Change, there is only the Scope. Strangely enough, setting an immutable deadline for a Project can be very liberating and often contributes to Project success.

Time-Boxed Meetings and Projects

The most famous Time-Box in Software Development had everyone from CEOs and CIOs to Developers wringing their hands and lamenting. It even had books Written about it. A few of you will remember “Y2K”. Every Application globally had to be vetted and Changed. Well thankfully, the world did not come to a end. What’s more most of the Projects completed successfully within the biggest Time-Box ever.

Time-Boxed Meetings: Why Time-Boxing is a Good Thing

In Traditional Projects, the Scope is Fixed. While a timeline and budget plan have been approved for the Project, both Time and Budget Overruns are possible. These components are often expanded while attempting to satisfy every Requirement in the Scope.

An Agile Project has a Fixed cost and end-date. These project components cannot change. Changes can only happen to the Scope of the Product under Development.

Changes are both anticipated and welcomed in Agile projects. This does not mean that all Changes are Accepted and applied to the Product. Changes are carefully vetted to ensure that they are critical to the Delivery of a “Minimum Viable Product” (“MVP”). Changes are not made just for the sake of Change. What is more, when the Project runs out of time, any Product Features that were not Developed are discarded. The discipline of tackling the highest Priority Work first indicates that any Work left over at the end of the Project was low Priority. These items are least likely to impact the Viability of the new Product.

Time-Boxed Meetings and Scrum

If the Project is a Scrum Development, there is even more Time-Boxing within the Project. A Scrum Project is broken down into Time-Boxed Iterations within the total Project, or Sprints, and all Meetings have an indicated duration.

Time-Boxing is the fifth of the Six Scrum Principles, which are:-.

1. ‘Em pirical Process Control’.
   2. ‘Self-Organization’.
   3.’ Collaboration’.
   4.’ Value-Based Prioritization’.
   5.’ Time-boxing’.
   6.’ Iterative Development’.

These 6 Principles interact and lead to effective and Agile Projects.
The Sprint – Time-Boxing to Deliver Consistent Results.

Time-Boxing Sprints

Each Sprint in a Scrum is also Time-Boxed. This allows the Project to be broken down into Manageable units of a Fixed duration. The time interval is normally 2 to 4 weeks. The Sprint however can be as short as one week or as long as 6 weeks. What is important is that each Sprint has the same Time-Box.  The reason for sticking to the fixed duration is that it makes it easier for the Team to determine how much Product they can Deliver in the next Sprint, based on the previous Sprint(s).

Each Sprint is Initiated during a Sprint Planning Meeting, and concluded with a Sprint Review. This is an Iterative Process, which is repeated up until the Project is complete. The Time-Boxing of a Sprint develops Scope Flexibility in a variety of ways:-.

• In a Traditional Project, the Stakeholders only get to see the Product when the Project is close to its end. This is during User Testing. This is an essential phase in the project. However the majority of the Time and Budget has often been spent in getting to this stage. Scrum Projects are different. The aim is to Deliver as early and as often as possible.
• During the Sprint Review, the Stakeholders get the Opportunity to examine the Product Developed to date. During this meeting they can request Changes.
• If the Scrum Project is going off track, it can be identified early and modifications can be made.
• If for some reason the Project needs to be cancelled (for example, the Product is no longer needed), the end of a Sprint is a tidy place to stop.
• Whatever Work is not finished and approved at the end of the Sprint can be “Done” in the next Sprint. This is unless that was the last Sprint, in which case the Project is complete.

We found these books great for finding out more information on Agile Scrum:

Segmenting in Scrum Projects

By segmenting a Scrum Project into Sprints, Project Risk is reduced:-.

• The Stakeholders understand when every review is due and can organise their time around these Fixed dates.
• If a change is Required, Stakeholders know that the Change Request need to be lodged and authorized before the next Sprint starts.
• The Costs are understood at any point in the Project since the number of Team members is Fixed. The Sprint is also Time-Boxed, so it is simple to compute the expenses spent at any point.
• The Stakeholder confidence level increases with each Sprint as the Product Developed to date is Demonstrated. This is demonstrated during each Sprint Review Meeting.
• It is really easy to stop the Project at any time, not just at the end of a Sprint, if this is required to be Done. The Scrum Product Owner has the authority to do this.

It is not only the Sprints that are Time-Boxed. The Ceremonies, or Meetings that are part of the Scrum Framework, also have Recommended Time Constraints.

Ceremonies – Making Meetings Effective.

There are 4 different Meetings that comprise part of each Sprint Iteration. These are Time-Boxed as well, to ensure that those in the Meeting are Focused on the most important Items to be discussed:-.

• The Daily Stand-up. The Agile Scrum Master will step in and remove any Roadblocks encountered by the Team if it is in their power to do so.
• The Sprint Planning Meeting is held prior to each Sprint and its length is linked to the length of the Sprint. For a four-week Sprint, about 8 hours ought to be set aside.
• The Sprint Review Meeting, which is held at the end of each Sprint, is normally Time-Boxed to 4 hours for a four-week Sprint. The Scrum Development Team do a “Show-and-Tell” of the Product Developed to date. This is understood as “Demonstrate and Validate Sprint” in the Scrum Process.
• The fourth Meeting is the Sprint Retrospective, which is Time-Boxed to 4 hours for a four-week Sprint. Any lessons learnt during the current Sprint can be used in the next Sprint. This creates a Flexibility in the Process architecture, as the Process can be modified to optimise Delivery.

We found these books great for finding out more information on Agile Scrum:

A Blend of Flexibility and Control.

Time-Boxing exerts control over the Scrum Project. It prevents overruns of Time and Scope Creep. Only so much can be accomplished in the time assigned. Yet at the same time, it enables Flexibility in Product Design. This is because Changes to the Product are enabled while under Development. A Scrum Project has lots of uncertainties, which diminish as the Project Progresses. By using Time-Boxing, the uncertainty of time to execute is removed from the Project, as the Timeframe is prescribed and known by everyone involved in the Project.