Chapter 13: Timeboxing

Previous chapter: 12 Modelling

More in this section... Chapter 1: Introduction Chapter 2: Choosing DSDM Chapter 3: Philosophy Fundamentals Chapter 4: Principles Chapter 5: Preparing for Success Chapter 6: Process Chapter 7: Roles and Responsibilities Chapter 8: Product Chapter 9: Workshops Chapter 10: MoSCoW Prioritisation Chapter 11: Iterative Development Chapter 12: Modelling Chapter 13: Timeboxing Chapter 14: Peoples, Teams and Interactions Chapter 15: Requirements and user stories Chapter 16: Project Planning and Control Chapter 17: Tailoring the DSDM Approach Chapter 18: Appendix A Glossary Chapter 19: Appendix B Project Approach Questionnaire (PAQ) Chapter 20: Appendix C Index Chapter 21: Disclaimer and Copyright

13 Timeboxing

13.1 Introduction

Timeboxing is one of DSDM’s key practices.

DSDM defines a Timebox as a fixed period of time, at the end of which an objective has been met. The Timebox objective is usually completion of one or more deliverables. This ensures the focus for a Timebox is on achieving something complete and meaningful, rather than simply “being busy”. At the end of a Timebox, progress and success is measured by completion of products (requirements or other deliverables) rather than completing a series of tasks.

The optimum length for a Timebox is typically between two and four weeks – long enough to achieve something useful, short enough to keep the Solution Development Team focused. On a very short and rapidly moving project, it is possible to have a Timebox as short as a day. In exceptional circumstances, a Timebox might be as long as six weeks. The disadvantage of longer Timeboxes is that the team may lose focus. By evolving the solution through a series of short Timeboxes, the team is able to more frequently assess their true progress – “What have we delivered?” If their progress is not meeting their own expectations, this provides early warning of problems, and an early opportunity to address the problems.

Timeboxing is more than just setting short time periods and partitioning the development work. It is a well-defined process to support the creation of low-level products in an iterative but controlled fashion. Timeboxing incorporates frequent review points to ensure the quality of those products and the efficiency of the Iterative Development process.

By managing on-time/on-target delivery at the lowest level, on-time and on-target delivery at the higher levels can be assured. Initial MoSCoW prioritisation of the work for the Timebox and continual re-assessment of what can be achieved in its agreed timeframe ensures that timeboxes finish on time every time and deliver a working solution to meet business objectives in line with business expectations - “No nasty surprises”.

The Project Increment and the entire project can also be considered as Timeboxes, as they share the characteristics of delivering a fit-for-purpose solution in a pre-set timeframe. These higher-level Timeboxes are managed through the control applied at the lower level – the Timebox. Unless qualified by Project or Increment, the word Timebox will always refer to a Timebox during the Evolutionary Development of the phase.
 

13.2 Timebox Options

Every timebox begins with a kick-off and ends with a close-out. Beyond this, DSDM recognises two styles of timebox:

• A DSDM structured Timebox
• A free format Timebox

The choice of Timebox style may be driven by factors such as the availability of the Business Ambassador and other business roles or the type of product being developed.
 

13.3 A DSDM Structured Timebox

This is the original DSDM-style Timebox, which provides a standard, repeatable internal structure to a Timebox.

The structure within a Timebox is very useful to allow forward planning of the times when the Business Ambassador will attend specific planning, feedback and review sessions. As well as these specific planned sessions, there is still an expectation of some day-to-day business engagement, e.g. attending Daily Stand-ups and timely response to urgent questions. By projecting this structure forward to future Timeboxes, it becomes possible to schedule the various Timebox control points (kick-off, the three reviews, close-out) for all the Timeboxes in the Project Increment. Where a Business Ambassador is trying to manage a very busy diary, this can be a great help.

The DSDM structured Timebox also provides a framework plan for the timebox, focussing Iterative Development activity within the Timebox to ensure convergence on an accurate business solution. With this structure, the Solution Development Team know when they should have completed their initial investigations (by the end of week one in a three week Timebox), they know when they should be nearing a conclusion and have their product nearly ready (by the end of week two in a three week Timebox). With this structure, the Solution Development Team know that the final few days are focused on final tweaks and fine-tuning, to ensure the Timebox closes cleanly. At any point during the DSDM structured Timebox, the whole Solution Development Team has visibility of progress and early warning if the overall Timebox objectives are at risk.

A DSDM structured Timebox comprises three main steps:

• Investigation
• Refinement
• Consolidation

Each of these steps ends with a review.

Figure 13a: A DSDM structured timebox

 

13.3.1 Timebox Kick-off

The aim of the Timebox Kick-off is to:

• Review the Timebox objectives, as outlined in the Delivery Plan, to gain a common understanding of what is to be achieved
• Ensure that it is still feasible within the Timebox to deliver what was initially expected during the Foundation phase, and to re-plan accordingly if this is no longer possible
• Where possible, agree the acceptance criteria for each product to be delivered within the Timebox
  • If it is not possible to agree this level of detail at the Timebox Kick-off, then agreement can be deferred to the end of Investigation but, in this case, high-level acceptance criteria must be agreed until the additional detail is available. (Going into a Timebox without an understanding of the acceptance criteria is extremely risky)
• Review the availability of all members of the Solution Development Team (including the business roles) to participate in Timebox activities for this Timebox
  • Commitment to delivery is based on pre-agreed resource levels at the project level. However an individual’s availability can vary between one Timebox and another, for example, due to planned time off
• Highlight any known dependencies (internal or external) that may affect this Timebox. The Solution Development Teams dependencies could be
  • Internal - other Solution Development Team’s on this project working concurrently in parallel Timeboxes
  • External - people or projects outside the team’s control that may impact this project

The Kick-off should be attended by all members of the Solution Development Team (including Business Ambassador(s)) who will be working in the Timebox as well as the Project Manager, the Technical Coordinator and the Business Visionary.
 

13.3.2 Step 1: Investigation

The aim of Investigation is to provide a firm foundation for the work to be carried out during Refinement and to clarify further the requirements and their acceptance criteria. Investigation entails the Solution Development Team jointly investigating the detail of requirements and agreeing how these requirements will be met as part of the Evolving Solution. This detailed information may be captured as part of acceptance criteria, against individual requirements, or as an elaboration of the Prioritised Requirements List.

Acceptance criteria should be confirmed as correct and providing appropriate coverage of the scope of each requirement. Whenever possible, an initial model or prototype of the solution is created to demonstrate an understanding of the requirements and to provide early visibility of the solution for assessment and feedback.

During Investigation, the entire team should work together on the full set of requirements agreed for the Timebox at the kick-off. It is necessary to understand the detail and priorities of the work intended for completion in the Timebox, so that informed decisions can be made later about which lower priority requirements may be dropped if necessary.

Some very early testing may be possible and is to be encouraged, but during investigation the main test focus is to work with the Business Ambassador and the Business Analyst, as well as the rest of the Solution Development Team, to clarify acceptance criteria and to start planning testing for this Timebox.

At the end of investigation the whole Solution Development Team review the following:

• Dependencies:
  • The team ensure they understand any dependencies within this Timebox on teams working in other parallel timeboxes on this project (concurrent teams) or elsewhere in the business, and between the requirements they are addressing
• Timebox Plan:
  • The team informally review the work still to be done, and agree which members of the team will be working on what. This ensures that no single individual is overloaded. This informal review validates the Timebox Plan (or highlights if the Investigation work has shown that the Timebox Plan is no longer viable, so that remedial action can be taken (see Chapter 11- Iterative Development for full details
• Risks:
  • Based on the information gained from the investigation, and risks recognised for this Timebox from the Delivery Plan and risk log, the Solution Development Team analyse the risks associated with this Timebox and, on that basis, ensure an acceptable balance of requirements of differing priorities in accordance with the MoSCoW rules The feedback from this review is captured as a Timebox Review Record (which can be as simple as a brief email, confirming what has been agreed). The investigation feedback is used to drive the next step in the Timebox – Refinement – and ensures the Solution Development Team can fully commit to achieving the Timebox objectives, based on an enhanced level of understanding.

A formal, documented review involving Business or Technical Advisors with responsibility for legislative or corporate compliance may be used as a demonstrable form of control over the Evolving Solution and provide a valuable audit trail.
 

13.3.3 Step 2: Refinement

The aim of Refinement is to complete as much of the development work as possible, including testing the products(s). Development and testing are carried out iteratively; the primary objective is to meet the detailed acceptance criteria previously agreed (at the latest, by the end of Investigation) but also to keep the focus on the current business need. The order of the work should be driven by the MoSCoW priorities for this Timebox but should be influenced by other factors, such as:

• A sensible development order from a technical perspective
• Availability of specific resources such as Technical Advisors, Business Advisors
• Any known cross-team dependencies

Refinement ends with a review with the Business Ambassador(s) and, where appropriate, other stakeholders, such as Business Advisors who have been actively involved in this Timebox, and the Business Visionary. By this point (end of Refinement) the work for this Timebox should be nearly ready.

The review determines what actions are necessary to achieve full completion of the work according to the acceptance criteria by the end of the Timebox. No new work should be started after this point. Final feedback (fixing minor outstanding issues) requested at this time should be carefully considered and prioritised. Any significant demand for change at this point often exposes a lack of appropriate involvement of business roles previously during this Timebox - a lesson to be learned for the future.

This review would typically involve a demonstration of the product developed within the Timebox. The feedback from this review is captured as a Timebox Review.

Again, with appropriate formality, this review can be an effective demonstration of legislative or corporate compliance.
 

13.3.4 Step 3: Consolidation

During Consolidation, the actions agreed at the Refinement review are carried out, together with final testing and any work required to satisfy organisational or project standards. Examples of this could be holding a peer review, or migrating code to a different environment. Any final quality control checks are carried out by the Solution Development Team to ensure all products or requirements/User Stories meet the business need to an acceptable quality. Consolidation ends with a review to check whether the Timebox objectives have been met. Any products

not meeting the agreed acceptance criteria by this point (the end of the Timebox) are deemed not to have been delivered. These undelivered products remain open on the Prioritised Requirements List.

Formal sign off here, or during close-out, by qualified advisors will acknowledge compliance of the solution with corporate or legislative needs.
 

13.3.5 Timebox Close-out

The primary aim of the Close-out is to record formal sign-off or acceptance of all the products delivered from this timebox. An important secondary aim is to determine what is to be done about work that was initially part of the timebox but was not completed. Such work may be:

• Considered for the next Timebox
• Scheduled for some point later in the Project Increment or project
• Dropped from the Project Increment or project

If overall timescales are to be met, it is important to avoid the situation where unfinished work passes automatically into the next Timebox, without any consideration of the overall priorities.

A final aim of the Close-out is to look back on the Timebox, to see if there is anything that can be learned to make the Iterative Development process and/or Timebox management process more effective in the future. This on-going process of holding a short retrospective workshop as part of each Timebox close-out has a number of benefits:

• To allow the team to learn from their experiences in this Timebox.
  • To recognise and build on the good experiences
  • To recognise problems and avoid repeating the same mistakes in the future
  • To define issues to be resolved in the next Timebox
• To gather ongoing information for use in the later, more formal reviews (at the end of the Project Increment and at the end of the project)

Where the Timebox has been successful and where the team is already established, this retrospective workshop can be very short. If there have been problems during the Timebox, or if this is the first Timebox with a new team, the retrospective workshop may need additional time.

Depending on the time needed for the Close-out, it may be practical and sensible to run the Close-out back to back with the Kick-off session for the next Timebox. 

13.4 A Free Format Timebox

The free format Timebox reflects the style used by other popular Agile approaches such as a Scrum Sprint. A free format Timebox may be effective where the formality and structure of the DSDM structured Timebox is not possible or helpful.

The free format Timebox also starts with a Kick-off and finishes with a Close-out. However in between, there may be any number of formal or informal review points. Typically the Solution Development Team will pick up one or more products or requirements/User Stories and evolve these iteratively until completed. Completion means a product of requirement/User Story meets the previously agreed acceptance criteria. The Solution Development Team then pick up the next product or requirements/User Stories and repeat the process. This free format style relies on the Business Ambassador being available consistently to review and provide feedback on an ongoing basis.

Figure 13b: A free format timebox

 

13.5 The Daily Stand-Up

A key and integral part of all Timeboxes, regardless of the style adopted, is the Daily Stand-up. This is the Solution Development Team’s opportunity to share information across the team and to do any day-to-day re-planning and reorganising necessary when issues occur. However, it is important to emphasise that ongoing informal communication goes on between all team members during the day as needed, and not just at the Daily Stand-up.

On a daily basis, the Solution Development Team get together for a Stand-up session. The Stand-up usually takes place at the same time and same place each day (with the Timebox plan visible), so that others who are not part of the Solution Development Team may listen in. Normally facilitated by the Team Leader, the Stand-up is a daily opportunity for everyone to understand progress against objectives at a detailed level and to expose issues and blockers that may be getting in the way.

The Stand-up:

• Has the following active participants:
  • All members of the Solution Development Team including Business Ambassador(s)
  • Any Business Advisors actively involved in this Timebox
  • Any Technical Advisors actively involved in this Timebox

• Typically uses a simple format in which each participant in turn describes:
  • What I have been doing since the last stand-up that helps achieve the Timebox objectives
  • What I will be doing between now and the next stand-up to help achieve the Timebox objectives
  • What problems, risks or issues (blockers) I have that will prevent me or the team achieving the Timebox objectives

• Has a short and fixed duration – normally no longer than 15 minutes
  • 2 minutes per participant + 2 minutes is a good guide

• Is ideally held with all participants standing in a circle by their Team Board; this is sometimes called an Information Radiator

• Re-enforces the desire to keep the session short and informal and to keep everyone focused
  • Teleconference Stand-ups (dial-ins) may be necessary where the team is split across multiple sites. However, for choice, this works better if groups at each site get together in a room and dial in to the groups at the other site(s). For teleconference Stand ups, it becomes even more important to use the suggested format(as bullet a a above) to provide a simple structure for the communications. For teleconference Stand-ups, the team need to decide how the Team Board will be used. In these circumstances, it may be an electronic version, rather than a physical area

• May be attended by other roles e.g.
  • The Business Visionary – in order to keep in touch with progress, to provide on-going visible support
  • The Project Manager – in order to observe progress and pick up escalated issues
  • The Technical Coordinator – in order to keep abreast of technical decisions and pick up escalated technical issues

 It is important that the Stand-up is used to identify problems and to agree who needs to participate in solving any problems that arise. The Stand-up should not attempt to solve these problems if reaching a resolution will take any more than a minute or two. It is common practice for problems to be taken off-line. This allows for follow-up discussions which are not run under stand-up guidelines and which only involve those who are directly impacted.

The Stand-up also provides the primary mechanism for the Solution Development Team to track progress and exert the necessary flexibility and control over their work to ensure on-time delivery of the agreed products by the end of the Timebox.

Daily Stand-ups are also an effective technique when used outside a Timebox, for example during Foundations, or in any circumstance where informal and on-going communication needs to be embedded as part of “the way we do things”.
 

13.6 Dealing with Change within a Timebox

Iterative Development is what enables a team to deliver a product that is genuinely fit for its intended purpose by the end of a Timebox. Converging on the accurate solution is achieved through constant refinement of the product, based on review by the business, led by the Business Ambassador and supported by the Business Analyst. It is vital that the decisions about whether, at any given time, a solution appears right, or needs to change to make it right, are both quick and sure. If decision-making is not quick and sure, there is a real risk that significant time will be lost (by waiting for decisions to be made) or wasted (as a result of decisions being overturned). It is important that all members of the Solution Development Team are appropriately empowered to handle any change that falls within the agreed scope of the Timebox objectives, without the need for a formal change control process that reaches beyond the team.

As a rule of thumb, the following scenarios always mean a change of scope and therefore need more formal management (outside the empowerment of the Solution Development Team):

• Changing the breadth of the solution (i.e. adding to the high-level requirements or removing Must Have requirements)
• Increasing the percentage of Must Have effort, either by introduction of new Must Have requirements, or by upgrading Won’t Have, Could Have or Should Have priorities to Must Haves

However, negotiation around the detail (the depth) of the solution can generally be handled by the empowered Solution Development Team without the need for any escalation or formal approval by those outside the Solution Development Team

Regardless of whether changes are deemed to impact scope or not, typically the Solution Development Team is empowered to operate within agreed boundaries without the need to escalate to the Project Manager or other project-level roles.

However, all changes to the content of a Timebox must be agreed and accepted by the Solution Development Team as a whole, and must not be simply imposed on them or decided by one individual member of the Solution Development Team in isolation.

Boundaries of empowerment should be established by the end of Foundations and reviewed for effectiveness on a regular basis (as a minimum, at the end of each Timebox). 
 

13.7 Timeboxes – The Wider Context

Application of the timeboxing practice (described above) in conjunction with the practice of MoSCoW prioritisation ensures each Timebox delivers a fit-for-purpose product in the agreed timeframe. As each Timebox delivers fit-for-purpose products on time, then this indicates that the Project Increment is on track and thus the project as a whole is on track.

Figure 13c: DSDM timeboxes in the context of increments and project

13.8 Summary

Timeboxing is one of DSDM’s key practices and is used in combination with the practice of MoSCoW prioritisation to ensure on-time delivery. At the lowest level, the Timebox maintains focus on delivery in the short term (weeks or even days). This provides control at the lowest level, as well as a clear indication of the health of the project overall. If Timeboxes are successfully delivering the Must Haves and the Should Haves (the expected case) at the agreed time, then the estimating process is working well enough, the team is working effectively, the delivery plan is being validated and the risks are being managed. This Timebox-level confidence feeds upwards to instil confidence at the Project Increment level and the project level.

Next chapter: 14 People, Teams and Interactions