Instinctively, when we hear time-boxing or hear that a Project or activity is “Time-Boxed”, we consider rigidity. One of the most important factors in any Project has been Fixed. We have no freedom to request for an extra day, week or month to finish.
We have less room to manoeuvre. If the Project is following the Scrum Framework our team size is fixed. We can not get in touch with a horde of Developers to contribute to the Team and develop more Work. Our Team numbers must remain fixed from the very first Sprint. We are therefore even more Limited as to what can Change, there is just the Scope. Strangely enough, setting an immutable due date for a Project can be extremely liberating and frequently contributes to Project success.
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. Many of you were too young to have had any participation in this crisis. Some of you will know of “Y2K”. Every Application internationally had to be vetted and Changed. Code that did not cater for the Calendar running over to the first of January 2000 was the cause of the concern. Fears for the Global Economy going belly-up and going without running water or electricity were anticipated. The world did not end that night. What’s more the majority of the Projects completed effectively within the greatest Time-Box ever.
Why Time-Boxing is a Good Thing
In Traditional Projects, the Scope is Fixed. The timeline and budget must be approved for the Project, however both Time and Budget Overruns are possible. This is due to the fixed scope and the attempts to fulfill every Requirement.
An Agile Project has a Fixed cost and end-date; Changes take place to the Product under Development. These Changes are both anticipated and welcomed. This does not mean that all Changes are Accepted. Change requests are carefully vetted to make sure they are vital to the Delivery of a complete but extremely Lean Product. This is referred to as the “Minimum Viable Product” (” MVP”). There must not be Changes for the sake of Change. What is more, when the Project runs out of time, any Product Features that were not Developed are disposed of. The discipline of tackling the highest Priority Work first means that any remaining Work at Project end was low Priority.
Time-boxing & Quality
By Time-Boxing an Agile Project, the Focus is on the Delivering a Quality Product within the time defined. However, if the Project is a Scrum Development, there is a lot more Time-Boxing within the Project. A Scrum Project is broken down into Time-Boxed Iterations or sprints. All Meetings also have a maximum duration. The timekeeper for all Time-Boxes is the Scrum Master. The Scrum Master has the most comprehensive knowledge of the Scrum Framework. Their Task is to see that the Team follows the suggested Scrum Processes.
Time-Boxing is the fifth of the Six Scrum Principles, which are:-.
- ‘Em pirical Process Control’.
4.’ Value-Based Prioritization’.
6.’ Iterative Development’.
These 6 Principles connect and lead to efficient and Agile Projects.
The Sprint – Time-Boxing to Deliver Consistent Results.
Each Sprint in a Scrum is Time-Boxed. This allows the Project to be broken down into Manageable pieces with a Fixed duration. The time interval is usually 2 to 4 weeks. However a sprint can be as brief as one week or as long as 6 weeks. What is necessary is that each Sprint has the exact same Time-Box (this is recommended and not authoritative). The reason for adhering to the exact same period is that it makes it much easier for the Team to identify how many features they can Deliver in the next Sprint.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Time-boxing the Sprint Planning Meeting
Each Sprint is Initiated during a Sprint Planning Meeting, and concluded with a Sprint Review. This is an Iterative Process, which is duplicated up until the Product is finished or the Project runs out of time, whichever comes. The Time-Boxing of a Sprint develops Scope Flexibility in a number of methods:-.
- In a Traditional Project, the Stakeholders only get to see the Product when the Project is close to its end, when User Testing is required and the majority of the Time and Budget has been spent. This is unlike a Scrum Project, where the aim is to Deliver as early and as possible.
- During the Sprint Review, the Stakeholders get the Opportunity to take a look at the Product Developed to date. If Changes are required, they can be Requested before the next Sprint starts.
- If the Project is going off track for some factor, it can be detected early and changes can be made.
- If for some reason the Project requires to be cancelled (for instance, the Product is no longer needed), the end of a Sprint is a tidy place to stop.
- Whatever Work is not completed and approved at the end of the Sprint can be “Done” in the next Sprint.
Time-boxing & Risk
By segmenting a Scrum Project into Sprints, Project Risk is minimised:-.
- The Stakeholders know when every review is due and can arrange their time around these Fixed dates.
- If a change is Required, Stakeholders understand that the Change Request needs to be lodged and authorized prior to the next Sprint begins.
- The Costs are understood at any point in the Project due to the fact that the number of Team members is Fixed and since the Sprint is Time-Boxed, it is simple to calculate the to-date costs at this point.
- The Stakeholder confidence level increases with each Sprint as the Product Developed to date is Demonstrated in each Sprint Review Meeting.
- It is extremely easy to halt the Project at any time, not just at the end of a Sprint. If this needs to be Done, the 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, likewise have Recommended Time Constraints.
Ceremonies – Making Meetings Effective.
There are 4 Meetings that comprise part of each Sprint Iteration. These are Time-Boxed too, to ensure that those in the Meeting are Focused on the most essential Items to be talked about:-.
- The Daily Stand-up. The Scrum Master will step in and remove any Roadblocks experienced by the Team if it is in his power to do so.
- The Sprint Planning Meeting is held before each Sprint and its length is connected to the length of the Sprint. For a four-week Sprint, about 8 hours need to be set aside. This ought to be enough to determine the Work (User Stories) to be taken on in the Sprint and the Complexity of each Story.
- The Sprint Review Meeting, which is held at the end of each Sprint, is generally Time-Boxed to 4 hours for a four-week Sprint. The Development Team do a “Show-and-Tell” of the Product Developed to date. It is understood as a “Demonstrate and Validate Sprint” meeting in the Scrum Process.
- The fourth Meeting is the Sprint Retrospective, which is also Time-Boxed to 4 hours for a four-week Sprint. Any lessons learnt during the present Sprint can be applied to the next Sprint. This creates a Flexibility in the Process architecture, as the Process can be modified to optimise Delivery.
A Blend of Flexibility and Control.
A Scrum Project have many uncertainties, which reduce as the Project Progresses. By using Time-Boxing, the uncertainty of time to execute is removed from the Project,
The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.
Thank you for choosing us to learn about the Agile Scrum Framework.