Agile Project Initiation

One company I worked with called the start of the project the “Blueprint” as it is about roughly shaping the project and product. “Inception” is another common term for this phase in agile projects. This article outlines traditional project initiation then delves into more detail on Agile Project Initiation.

Traditional Project Initiation

Initiating is one of the five project management process groups in the Project Management Body of Knowledge (PMBOK) from the Project Management Institute (2004).

In the UK project initiation usually means writing a Prince2 style Project Initiation Document (PID) or the equivalent.  Once you have the PID the Requirements Capture, Analysis and Design activity can begin.  All of which is rather time consuming.

The Project Initiation Document (PID)

The defining feature of the Prince2 Project Management method is the PID. It can take a considerable amount of effort to write this document. OGC: Project Initiation Document (PID) gives the suggested content:

  • As a minimum the document should answer the following fundamental questions about the project:
  • What the project is aiming to achieve
  • Why it is important to achieve it
  • Who will be involved in managing the process and what are their responsibilities
  • How and when the project will be undertaken
  • The PID has to answer the above questions to a sufficient level of detail to maintain control of the project. The document should cover the following areas:
  • Background, explaining the context of the project, and how we have arrived at the current position of requiring a project.
  • Project Definition, explaining what the project needs to achieve. Under this heading will be:
    • project objectives
    • defined method of approach
    • project scope what is included and what not
    • project deliverables and/or desired outcomes
    • exclusions
    • constraints
    • interfaces
    • assumptions
  • Project organisation structure, detailing who is going to be involved and what their responsibilities are (team management structure and job descriptions)
  • Communication plan, describes how the project stakeholders will be kept informed during the project
  • Project quality plan
  • Project controls, laying down how control is to be exercised within the project, and the reporting and monitoring mechanisms that will support this
  • Business case, covering the estimated costs, risks and benefits. The Business Case will require regular review throughout the project and may require updating
  • Initial project plan. The plan will be reviewed and further developed at regular intervals during the project
  • Risk register containing details of the identified risks so far. The Risk Register will be reviewed at regular points during the project to assess progress on managing risks and to identify new risks that may have appeared

Requirements Capture, Analysis and Design

These phases are all about identifying the requirements and then transforming them into a format suitable to hand to developers.  The Requirements (see Project Scope) are usually in business language.  Analysis, usually done by a systems or business analyst, extracts the logical requirements.  Design attempts to show how the logical requirements which be met technically.  These phases are all time consuming, happen in sequence, and involve different people at each stage.

Agile Project Initiation

The Agile methods are beginning to acknowledge that some upfront work is required to ensure project success. Project Initiation includes all the work necessary before full scale coding begins.

Agile Project Initiation includes these steps:

  1. Find/Write Project Brief
  2. Form the team
  3. Initial Plan
  4. Initial Requirements
  5. Initial Infrastructure

The difference between Project Initiation and the equivalent in a traditional waterfall process is that Project Initiation is time boxed and the Agile Team do the work.  a couple of days is all you need for a small project and a month is fine for a large project. Given the short time period the initial deliverables will not be perfect but perfection is not the aim. The idea is to do barely sufficient work to begin developing a solution. For some deliverables, e.g. Release Plan and Risks and Issues Log, these will be only the first version of many created during the project.

For further information on activities to include in Project Initiation, check out the Business Study in DSDM (2002) and Iteration Zero in XP (Beck 2000).

Find/Write Project Brief

Strictly speaking the Project Brief should exist before the project but in reality this often hasn’t been done and the Agile Project Manager should to write/find it.

See Agile Pre-Project

Agile Lifecycle Form TeamForm the Team

The Agile Project Manager mobilises the Agile Team and ensures the Agile Team has an appropriate work space and support.

An Agile Team should contain the mix of skills required to deliver the product. Common skills are Project Managers, Product Owner, Designers, Developers and Testers.

Agile promotes close collaboration between team members so advocates co-location of the team members. Co-location makes for better channels of communication and counters Conways Law which suggests poor channels of communication may be reflected in the structure of the end product (Wikipedia: Conway’s Law). If the team have a dedicated work area then they can use their workspace to display visible progress towards their Timebox Goal.

This is a good opportunity to do the following.

  • Identify and arrange any necessary training
  • Set up recurring meetings and book rooms for Timebox Planning, Demos (also book a projector) and Retrospectives
  • Arrange for the team to sit together
  • Order a board if you need one
  • Prepare for the first Timebox planning ( See: Timebox Pre-Planning)
  • Create a project space and decorating it with material, staking it as the informative workspace as defined in the Agile glossary.

See Agile Roles and Responsibilities

Agile Lifecycle Initial PlanInitial Plan

The Release Plan is a reflection of features to be developed over time. The desirable features of a product are prioritised and then divided by Timebox with the most important features developed first. See the section Release Plan for more details. The division by Timebox is a result of the current velocity of the team being mapped against the current story point backlog for the project.

This is a good time to start the Risks and Issues Log.

See Agile Project Planning, Agile Project Estimating, Agile Risk Management

Agile Lifecycle Initial RequirementsInitial Requirements

The Product Owner is responsible for delivering the initial requirements during Timebox Zero.

There is no need to provide detailed requirements for subsequent Timeboxes at the start of the project. This will allow requirements to develop during the project with minimum overhead.

In terms of requirements that means doing:

  • High level requirements for the entire project
  • Detailed Requirements for Timebox One

The high level requirements are for the entire project.  Facilitated workshops are an effective mechanism for eliciting the requirements from the stakeholder group fast. The high level requirements drive the the Release Plan.

Agile is about doing the barely sufficient documentation to facilitate the next step in the process.  That means only enough detailed requirements are specified, agreed and understood to keep the team busy for the first one or two Timeboxes. Ideally the detailed requirements include Visual and User Experience Designs.

Silicon Valley Product Group recommend a a High Fidelity Prototype rather than using documents to describe the target system.

See Agile Project Scope and Agile Project Control

Agile Lifecycle Initial InfrastructureInitial Infrastructure

the technical staff set up the infrastructure for the project during Timebox Zero. This includes:

  • Environments
    • Developer and tester machines
    • Servers (development, continuous integration, test, UAT) including hardware and operating system, web servers, application servers, databases and permissions
    • Team Wiki
    • Set up and configure a bug tracker, agree bug process
  • • Version control and builds
    • Source Code Control repository (e.g. SVN) with access for developers and tester(s)
    • Tools for Continuous Integration (e.g. Cruise Control, Nemesis)
    • Continuous Integration up and running on your project in your source code repository
  • • Test Driven Development frameworks
    • Tools for automated testing (e.g. JUnit, JMock, JSUnit, Selenium, FIT, Fitnesse, DBUnit, XMLUnit)
    • Agree method(s) and depth of unit testing
    • Agree methog(s) and depth of acceptance testing
    • Agree the high level scope and approximate timing or frequency of other tests, for example accessibility, performance, security
    • Decide, set up and configure a framework for acceptance test automation
    • Write just enough code to support the automated build, continuous integration system, and automated test framework in use.

The technical staff, led by the Technical Lead, also do the first high level version of system architecture.  The systems architecture document outlines both the hardware and software of the intended solution. It describes the target platform and (if different) the development platform. It also explains the software structure including major components and their interactions. [Some Agile methods are very keen on emergent design, but you have to start somewhere.]


Not really Agile per se but I thought it worth having a mention of the environments a development team will need. There are quite a few.

Promotion Path to Live
Environment Purpose When to use Release Control Who Controls
Development Where the developer does their thing. Always Controlled Developer
Continuous Integration Where the continuous integration build appears Always Uncontrolled
Automatic System Test Where the automatic tests run if the Continuous Integration box can’t handle the load. If have to split test because they run too slow Uncontrolled
Manual System Test Where the Testers check out stable releases. Always Controlled Tester
Automatic Integration Test To integrate all of the components when there are multiple development teams working on a shared product.  Kicked off by an automatic process. Multiple teams integrating Uncontrolled
Manual Integration Test Ditto but for the integration testers to use. Multiple teams integrating Controlled Integration Tester
Hot Fix Development To maintain a live copy of the software using Hot Fixes, whilst developing new functionality in parallel When system is live Controlled Developer
Hot Fix Continuous Integration Ditto; this is were the continuous integration build goes When system is live Uncontrolled
Hot Fix Pre-production Ditto; this is were the Hot Fixes are tested before going live. When system is live Controlled Product Owner
Pre-production This is where manual user acceptance testing usually takes place Always Controlled Product Owner
Production Live. Always Controlled Product Owner or Operations


Beck, K. (2000). Extreme Programming Explained: Embrace Change. Reading, Massachusetts: Addison-Wesley.

DSDM Consortium. (2002). Framework for Business Centred Development:Handbook for DSDM Version 4.1.. Author.

Project Management Institute. (2004). A Guide to the Project Management Body of Knowledge (PMBOK Guide) [3rd Edition]. Author.

OGC: Project Initiation Document (PID)

Silicon Valley Product Group

Wikipedia: Conway’s Law

9 thoughts on “Agile Project Initiation

  1. Pingback: Methodologies and Project Madness | beyondcenter

  2. Typo in this sentence: This is were manual user acceptance testing usually takes place.

    Were should be where

  3. Hi Steven,

    Thank you for the commendable effort to mark the differences between Agile and Waterfall. It is very thorough however I feel that your summary on Agile Project Initiation ignores Agile practices such as Atern (DSDM) and SAFe (Although some might suggest that it is not Agile). However I do think that:
    1. Find/Write Project Brief
    2. Form the team
    3. Initial Plan
    4. Initial Requirements
    5. Initial Infrastructure

    might be correct for certain types of project but might not fit big complex projects nor regularity industries. Agile initiation plan for those is very much required however the content of the plan is different than in waterfall

    • I have worked on large complex initiatives and this is the approach I use for those. For a well understood domain more work might be invested in each of the steps. However, my experience that no domains are well understood and starting in a light fashion is best even if you ramp up from there.

      I very much had DSDM in mind when I wrote this, although I’ve changed the language to make it more universal. Have a look at my Agile Comparison for more on DSDM including initiation.

      SAFe is a relative new comer to the field and was launched after this post. I’ve not had a reason to look at SAFe yet.

      I have not worked in a heavily regulatory environment so cannot comment on that aspect.

  4. Hi Steven,

    Agile remains controversial within the medical devices industry, and so I wanted your input as you seem to be experienced in agile & PM methods.

    I came to your blog from an article that linked to here. That article was about regulated software (for medical devices). I work in that industry (have many decades of experience therein).

    I’ve read a few of your blogs, and I must say your writing is on-point on many areas, and I believe you have not claimed Agile is applicable to highly regulated industries. You clarify in a comment above that you don’t have experience in regulated industries. I greatly appreciate your openness & candor.

    Based on my synopsis/understanding below of Agile/et al, I ask for your feedback on its strengths, weaknesses, applicability, etc. to highly regulated development methods.

    To me, agile (and related techniques) are about iteratively defining/developing/testing a system/software. Method: A tight-team spends a predetermined (small) amount of time going through ONE iterating of the task at hand (which coincide with/correspond to the traditional project phases: initiation, definition, etc.). After that iteration, they may iterate again (if the goal of that project phase is not met), or proceed to the next project phase (if project goal is met). At any time (at any project phase), the team/PM/scrum master/etc can decide to pull the team/subteam back to an earlier phase (based on criteria determined “on-the-fly” or as defined in the PM plan). Thus, iterations are the name of the game — the team/subteam repeat a task/phase until it’s “done”, then move on. At any time, if a issue/problem arises, the team lead/PM/master/etc decides (on the fly? like a dictator?) if you go back to an earlier phase or continue forward.

    The focus of each spin/cycle/iteration is mostly to minimize time/maximize efficiency of the team/work rather than on controlling product characteristics (e.g. quality output, defect detection, etc). Not to say product characteristics are not important, but it seems those are secondary/later goals and are not the primary focus of the team/subteam.

    The team/subteam/PM define up-front (at start of project) the criteria for when the project will complete. This can be based on any criteria, such as max number of cycles (end development after 7 iterations, testing after 20 iterations, etc), or perhaps end after a max time (eg, 4 months), or defect coverage (when 80% of defects/open-tickets are fully closed), post-Beta user satisfaction (less than 5 bugs reported per 100 users, monthly for 6 months post-release of Beta version), etc….. anything they define up-front.

    Overall, it’s about QUICK decisions, quick actions, and maintaining rapid forward momentum.

    Firstly, is this an accurate synopsis (I intentionally left out details — since I just want to know if this “so-far” synopsis is correct).

    Secondly, what’s your take on applications/limitations to Agile’s use for highly regulated software (e.g. medical devices/systems, space applications, mission-critical or life-support systems, etc)? Is it mostly meant for production/user software, or can it also apply to firmware (embedded), device drivers, real-time software, etc.?

    Thank you.

    • Dan O, thanks for dropping by. Your synopsis is pretty good although I’m sure some folk in the Agile community would object to some of the language … but I get that as well. For example people who emphasise a collaborative approach prefer not to see the dictator in their midst. 🙂

      As I said before I have not worked in a regularly environment so I am talking from a considerable point of ignorance. If I did find myself in such an environment my starting point would be mapping the value stream (a Lean / Kanban thing), i.e. mapping the steps in the process. The regulatory nature of the context means there are likely to be many and/or long steps at the end which are to assure safety. If I could send small bits of work through that process I would.

      Some of that might require batching the work items, e.g. external approval that costs a lot. In this case I would use small work items, in an iterative-incremental approach up until the point I have to batch the items. Then I would batch them and send the batch onward into the final processes. This is a common pattern with software teams that package releases for manual testing and deployment.

      Hope that helps.

        • And one more thought … the inspiration for Lean Software Development was the Toyota approach to designing cars. And that is why I’m confident the approach will work for firmware, device drivers, real-time software etc.

Comments are closed.