Save £12 Million every year > Save £3 Million every quarter   
The Big Agile Toolkit: no Dogma, no Bias, no Accreditation, no Exams & no Fees   
 Timeboxing  Timeboxing   Prioritised Delivery   Prioritised Delivery

For time boxing to work successfully the close co-ordination of activities and priorities inside the time box is important. In all projects we are faced with benchmark project management constraints and there are four of them: time, quality, cost & features. You will find in many books and articles that features are often referred to as scope.

However, the concept of features involves much more than just scope. Within the Toolkit, we look at all four constraints. We fix three of them and make one a variable that the project can adjust.

Most projects experience the four constraints of time, quality, cost and features. Trying to fix all these parameters at the outset of a project is impractical and is the root cause of many common project problems for project managers. The attempt to achieve impossible objectives such as this is contributory to many project failures.

In a traditional project, features (often called the scope or content) are fixed. The project will have spent significant time, money and effort into determining the needs, requirements and conditions to meet for a new project with the various project stakeholders. This is often achieved through the process of requirements analysis whereby all the requirements of the project are documented in detail sufficient for a detailed design to commence.

Meetings and workshops will have taken place with customers, management and users to elicit, define, understand and refine. Detailed analysis and requirements rework will have taken place to clarify ambiguities, contradictions and incompleteness in requirements. The cyclic process of this rework involve conducting early interviews, establishing and managing focus groups as well as prototyping the requirements and presenting them in documents and use cases.

The process can be very involved and time-consuming.

The requirements process will likely deliver one or more requirements specifications to describe the functional and non-functional requirements of the project. It may split them into the five popularly used FURPS classifications for requirements: functionality, usability, reliability, performance and supportability.

Whatever the method to uncover and derive the requirements of the project, there is evidently a significant investment by the project in the scope, features and requirements which explains why a traditional project demands that the features are fixed. In the Toolkit, we do not fix features. We ask the business and project team to describe the requirements at a high level with enough detail so they can be validated that their objective has been satisfied. However, it demands that requirements leave enough flexibility to allow the business to add features inside requirements if time and budget permits.

As we said elsewhere in the Toolkit on a traditional project, features are fixed. The time and costs (quality also) are variables though which are subject to change. As the project progresses, it is periodically measured and controlled. As the measurements indicate that a project is about to deliver a late, it will seek to add more resources. This will add to costs. Invariably it also adds to time as new resources require induction and a period of bedding in. This further pressure adds new demands for project communication and these demands further burden the end date. Finally, quality is the casualty as project features and important testing are abandoned to accommodate the revised resources and delivery dates.

In the Toolkit, we fix time, quality and cost. We choose a time i.e. end date. We discussed this at the very beginning of the Toolkit when we described a very important project delivery celebration. This date is mandatory, fixed and without debate. We define our quality by specifying the acceptance criteria for our deliverables and we estimate the work to prepare these on the basis of this level of quality. The estimate for our work based on the level of quality and the fixed delivery time coupled with any infrastructure expenditure gives us the fixed costs to deliver our project.

So, we know that we can deliver our project to the specified level of quality, on the desired date and within our planned budget. Developments, however, never go to plan fully. So we need flexibility somewhere to accommodate such variation demands. The flexibility we will deploy is in the richness of the requirements to be delivered. Let us look at this a little more. Requirements are business statements to achieve certain objectives. They come about as a result of deliverables and processes. Our deliverables and processes have defined levels of quality that we will achieve. However, it is in the extent to which the deliverable or the process meets requirements that we introduce flexibility to meet cost and time deadlines.

Let us look at an example. Let us imagine that you want to build a garage. Your requirement is a structure at the side of your property to house vehicles and you will gain access to the structure via your drive. Investigating your requirements further uncovers that you wish to house two vehicles and the structure will fail acceptance if the structure only occupies one vehicle. Furthermore, you demand a tiled and pitched roof. The roof tiles will match a precise specification and roof profile pitch will be 45°. A garage door fitted to the front of a four walled brick construction is required and the bricks will match those of the main property. The paintwork on the garage will also match that of the main property. The quality of brick and paint matching will be defined by your visual inspection at a distance of 15 m from the front of the property. There are many further parameters that you could set to further define your acceptance of the quality of the finished structure. Normally, as you add further features and deeper levels of quality this adds to the time and to the cost. In this example, we assume the details above describe the level of quality you demand. Now your delivery team will estimate the work to deliver the structure. The estimate will be based on the quality levels that you have specified. You have not asked for a gravel drive or an armour plated garage door, so you will not get these and the estimate will not include them. You have asked for four walls and this means that a car port will not satisfy your acceptance. So you can see there will be a lot of room for flexibility. Is the floor going to be reinforced and made from concrete? Are the interior walls going to be rendered and any windows fitted? There are many details that have not been specified and only a few quality criteria stipulated.

This is one of the challenges to define requirements in enough detail without compromising flexibility whilst at the same time maintaining the proposed solution within the bounds of an approximate budget. Often a user or business group will meet to discuss their requirements alongside an estimating team in order to derive the maximum number of requirements and the optimal quality within budget. The two teams will iterate costs along with requirements, adding and removing requirements whilst adjusting the estimate. Once agreed estimates are reached the requirements and allied quality criteria are documented to become part of the project documentation.

Extracting requirements can be a challenge in its own right and the Toolkit offers a user requirements workshop with key stakeholders to understand what they want and to understand the detail of the requirements.

A workshop helps to lead business users to participate and investigate the full requirement and helps them to commit to an agreed description of it. It is a method of getting your project team members to meet early in the process, to communicate and to start to build the team.

A workshop is a way to explore the preferences and technology options as well as an early opportunity to introduce the project way of working. Finally, an important deliverable for your requirements workshop is the Minimum Acceptable Delivery (MAD) the project will acknowledge for successful completion.


 Timeboxing     Timeboxing   Prioritised Delivery    Prioritised Delivery

Glossary:     a  »   b  »   c  »   d  »   e  »   f  »   g  »   h  »   i  »   j  »   k  »   l  »   m  »   n  »   o  »   p  »   q  »   r  »   s  »   t  »   u  »   v  »   w  »   x  »   y  »   z

#personas  »   #artefacts  »   #archetypes  »   #patterns  »   #change  »   #personas  »   #increasingoutput  »   #reducingvariation  »   #improveefficiency  »   #abstraction  »   #predictionandcontrol  »   #management  »   #organisations  »   #socialnetworktheory  »   #failfast  »   #quality  »   #waste  »   #complexity  »   #learning  »   #adapt  »   #inspect  »   #improvement  »   #models  »   #complexadaptivesystems  »   #informationflow  »   #sytemsthinking  »   #butterflyeffect  »   #unpredictability  »   #chaos  »   #emergence  »   #emergentbehaviour  »   #distributedcontrol  »   #continuousimprovement  »   #complexityscience  »   #gametheory  »  
 Agile In 6 Steps    |    Projectivity    |    Instant Agile    |    Risks    |    Auditing Agile Projects 
Big Agile Toolkit Book (Amazon Japan)   |   Big Agile Toolkit Book (Barnes and Noble)
Buy the Big Agile Toolkit Book   |   Buy the Big Agile Toolkit Kindle eBook
Time box management


The Big Agile Toolkit

 SPADE: Successful Pragmatic Agile Delivery Everytime™ 
Topic: 374  Page: 313/444  Progress: 70.5%
 About    |    Author 
Follow @BigAgileToolkit

This content can be copied to third parties for personal use if you acknowledge the source of the material with website URL ( and Twitter hashtag (#BigAgileToolkit).
In all other cases, no part of bigagiletoolkit or associated text or website may be copied reproduced or redistributed in any form or by any means without prior permission in writing from the author.
Agile Project Governance for Cost Conscious Companies™

All rights reserved.