CMMI Ltd Approach to AGILE
Note:- This page is still in development


In the early eighties MoD UK produced a procedure for software development DEF STAN 00-16/1, whilst in the states the Defence Supply Agency Manual 8200.1, dated August 1976 outlined a software lifecycle.  It is widely accepted the first document to define a practical approach to software development is the Military Standard Defence, System Software Development Standard DOD-STD-2167 dated 4th June 1985.  This superseded DOD-STD-1679A dated 22 Oct 1983 and was issued along with MIL-STD-1512 also 4th June 1985 to identify the process for Technical Review and Software Audits.   Document 2167A was replaced by Software Development and Documentation MIL-STD-498 dated December 1994.  This standard was supported by sixteen Data Item Sheets (DID).  MIL-STD-498 was adopted by software managers whilst leaving outsiders a little bemused.  CMMi came along early in the nineties to identify a much broader range of goals necessary to achieve best practice supporting software development.   IEEE/EIA 12207 was produced in 1995 by a consortium made up from industry and supported by US Government with the aim of replacing MIL-STD-498. 

Unlike defined software development processes, Agile is much more of a culture method of working.  Differing organisations adopt a slightly different approach.  What Agile does is to document and record a number of best working practices, many are not new and would have been learnt by an apprentice in previous years.  The focus has to be on delivering working code in short timeframes, no need to produce perfect UML models or always produce complex requirements documents.  It is however vital that the customer requirements are fully understood and agreed, the green boxes on the diagram provide supporting documents that will need to be addressed.  The following identifies how Agile has been adopted by CMMI Ltd. 

Agile Approach

An MS Project Schedule has been used to capture a number of Agile Methods From the diagram below click on a coloured box to obtain more detail.  See also Agile Practices.  The Schedule button will return you back to the schedule overview. 

Product Backlog

It is necessary to have a backlog of work.  This shall be a prioritised list of requirements and may be made up of system software components making up a user or customer requirement.  Without the need to schedule a backlog of work, Agile will add little or no value.  These will be made up of

  • ID - An unique identification.  This can be generated from the requirements capture tool.

  • Name - Short description which the team and customer will refer to.

  • Priority - The order in which the artefacts will be addressed.

  • P1 For Next Release (First Fix)

  • P2 Second fix for next release

  • P3 Desirable for release.  These will be moved to a P2 for a subsequent release if they have not been implemented.

  • P4 will be fixed at a subsequent release as per schedule and revaluated.

  • P5 will be undertaken when all other tasks are completed.

  • Initial Estimate - Produced by the team based on Analogy.  Project Manager has the responsibility to get this correct.

  • Notes - A description or other information about the component.

Initiation Meeting

This is a meeting involving all of the team which may be made up of three to twenty people, and may involve the customer.  The initial meeting is held at the start of a new product release and can be based on a Project Approach and Risk Review detail check lists.  Allow an hour for the approach and an hour for risk reviews.  If a customer is present for the approach meeting subsequently obtain their feedback information.  Risk reviews will be much more open if the customer is not present but needs to be judged based on commercial sensitivity.  The room needs to hold the relevant number in the team, a white board, flip chart and projector made available.

Sprint Planning

Have available a product backlog identifying the requirements and priority.  Understand the velocity and resources availability.  CMMI Ltd used a tailored FogBugs tool to identify requirement backlogs and to track bugs.  This identified unique ID's and task could be assigned to individual owners.  BugZilla provides a free and open source software tool that will do a similar job.  Excel can be used to produce a locally modified tracking tool.  Other tools available are VersionOne, XPlanner and ScrumWorks.  In the first instance use a white board to discuss the relationship of stories and get an overall picture from the team based on salient points.  Post-it notes can be used to produce the Work Break Down (WBS) key items in one colour supported by components or tasks in another, this way everyone is involved.  The use of a projector to show each of the backlog items for review and update information as it is discussed is good for bug tracking.  Both approaches require a subsequent update of the WBS and Schedule by the Scrum Master or Project Manager to finalise resources and priorities.  A story is deliverable and made up of a number of tasks.  By breaking the work down at this time will provide a more accurate estimate and realistic sprint plan.

The whole team involved in the sprint need to be present.  The responsibility for the products success rests with the Project Manager who may be considered as the representative of the sponsor. The Project manager needs to identify Product Owners from the team who may in turn seek support from other developers. It is important to take on board each persons diverse opinions and obtain estimates and buy-in and an understanding of the aims from the whole team.  Try not to have team members influenced by others and widely differing estimates.  Where large discrepancies exist then it will be necessary to go over the story again.  One team member may provide an initial estimate which can then be debated by the rest of the team.  What goes into a sprint is normally what the sponsor sees as important, however it is necessary in some instances to incorporate other features due to the future dependencies or match available skills.  Developers identify development time then add to this half as much again for testing and contingency. 

The Sprint Planning Meeting should ideally be no more than two hours. To achieve this the Project Manager may have had to have undertaken previous leg work.  If more time is required i.e. half a day, it may be beneficial to hold the meeting away from the normal place of work so as to focus concentration.  Decide on the stories to be included in the sprint based on priorities.  Trade offs of P2 and P3's may be necessary.  There should never be a lack of quality assurance or squeezing testing.  Instead scope has to be the option for compromise, if not additional time scale or resources will be required.  Sprint lengths depend on the task in hand but four to six weeks is comfortable. 

Identify how quality will be ensured, this may be by peer programming, code walkthroughs and independent QA testing.  Ensure this the necessary time for QA is recorded and planned.  The story has sufficient detail when the independent tester feels they have the necessary information.


This is from the UK rugby term where part of the team get their heads down in a huddle to sort things out.  CMMI Ltd tend to use the term scrum meeting to address a single issue such as progress or a components design.  This can be held as a Ten Minute Stand-up (Daily Scrum) each morning or as necessary by team members. It is important to have drop out rooms with a white board and flip chart to take away information. 

Burndown Chart

This can be successfully managed in Excel, however MS Project or Project Open Source is the correct tool for the job.  So as not waste valuable development resources this is owned and maintained independently to development by the Project Manager.  The Project Manager will also be tracking critical paths and potential bottle necks.  This should be updated and printed out on a plotter at salient times.  Each developer will update the requirements/bug tracking tool by sending the feature to test and identify progress on the printed out schedule when a task is completed. They will also see from the schedule the next task allocated to them.  This will align to the information in the requirements/bug tracking tool.   Treat bugs just like any other task, estimate time to fix and keep an actual record of time taken to aid evaluation of velocity.

An effective way to report progress is to produce a WBS at the start of the project about three levels down.  This needs to go on the wall with the schedule.  It also acts as a visual progress report for a sponsor.  Each box shows the name of the component or task, under each box mark the owner and the planned start and end date.  The main product and sub system boxes are light grey.   Task boxes are red until work has been started when after 50% progress they turn from red to red and yellow and yellow and green when they are presented to test.  Boxes go all green when successfully tested and bug free.  No boxes are removed unless a feature is no longer required by the system.  This WBS/PBS can be saved by date to show progress over the life of the project. 

Iterative Development

Deliver working software early and often.  Iterations can be one to eight weeks.  Allow one third of the effort for testing and bug fixing.  That would equate to a delivery every three months.  This is sometimes too often for a customer and it may be more convenient for a software update being released every six months.  In this case still plan on a one to eight week Iteration.


A presentation that portrays the customers agreed requirements.  Template available in Power Point.  This may be captured in a Requirements Specification.  This demo is also used to develop the test requirements.


It is important to understand velocity as without this planning delivery dates will be a guesses.  It is not just the velocity of the team that is important but the velocity of individual developers.  Some developers deliver code fast but then rely on rework to address issues, likewise a slower developer may produce fault free code.  Velocity also has to take into effect holiday periods and the introduction of new staff in the team requiring training from existing staff, it is necessary for the Project Manager to schedule accordingly.  See also "Estimating".