let us just give one final example to support this. Let us imagine you are working on a project. You are a developer working on a security login screen. You developed the screen yesterday and the screen went into assessment yesterday. There are some features still to develop and the assessment has identified some errors. Today, you attend the Daily Forum and you, of course, hear the comments of the business team from yesterdays assessment.

The business team from yesterdays assessment speak & describe the various activities they performed yesterday. One of the activities, of course, was the assessment of your security login screen. Naturally, they describe it as software of the most outstanding quality, but they identified a number of defects and would like the high priority defects repaired. They realise this will impact on the development of new features but prefer the defects to be fixed. The repair of high priority defects on the security login screen is added to the build and fix list.

At the Daily Forum, it is your turn to speak so you explain that yesterday you developed the security login screen. Today, you are going to develop the new security login features and (while you have the bonnet open) you will fix the high priority bugs which were added to the build and fix list by the business team, today. In this way we can simply, almost seamlessly, combine rework into the planned development to make sure it is in the next release and is assessed in time for the next shipment. You see now how all this starts to link together. So, regardless if you are convinced yet, let us progress the example a little more.

The Daily Forum ends. You return to your desk. You still have the source code for the security login screen waiting in your editor. You have the major features and design still fresh in your mind. You have told the Daily Forum that you intend to build the new features agreed and repair the high priority defects. You start on it immediately without delay, without waste, without breaking your stride. It is immediate responsive and it works.

Another very useful technique we deploy within the Toolkit is Just-In-Time Development. In this technique we only develop features when they are actually needed. Build the smallest you need but as soon as you need it and be pragmatic.

Remember also that we review estimates of our work throughout the development cycle, refining and improving our estimate as we go. As we adjust our build and fix activities, this influences our estimate of work to complete. The immediacy of the work and our reaction to it often mean we have little time to estimate at a low granular level. Look a little further at the section on Estimating to see how you make your estimating process fit for purpose too.