The context is a PMO running across two development groups, one doing Agile development, the other using the waterfall model. In order to come up with a common approach and engagement model, we would like to standardize roles, responsibilities, and definitions.

The "project" definition is somewhat fuzzy in the Agile world, because work is a collection of features/epics that are aligned to a value stream. A project is a more legacy concept of an activity that has a start/end date, with hopefully some value being delivered to customer.

How do we define "project" in the Agile world?

  • "one doing Agile, the other development"? Is the "Agile" group not doing development then? Or are they doing support/maintenance and the 'dev' team is creating new stuff?
    – Stephan
    Commented Jul 31, 2013 at 9:25
  • Sorry, typo...meant to say one group doing Agile, the other one using a Waterfall methodology.
    – Agile PMO
    Commented Jul 31, 2013 at 13:11
  • 1
    I think this is an X/Y question. "How do we define 'project' in the Agile world?" doesn't seem to be your real question. I think you're really asking how to standardize roles, responsibilities, and definitions across models. Yes, no, maybe?
    – Todd A. Jacobs
    Commented Jul 31, 2013 at 14:09

4 Answers 4


The definition of a project in agile terms is no different to that of a project in traditional terms. The difference is how the project is run and executed and the values behind the project.


Both agile projects and traditional projects:

  • have a start and end
  • may be constrained by schedule, scope or budget
  • should be for a single product; (lets not debate symantics)
  • run internally built or by external vendors
  • be part of a larger program or portfolio of work
  • deliver a product
  • deal with risk management and risk mitigation
  • If you look at PRINCE2 and PMBoK, both promote iterative approaches in the form of stages or phases. Most agile frameworks do to.


Agile recognises that we deal with complex technologies and requirements in a world of many uncertainties and ambiguities. In doing this the approach is more an empirical process control instead of following a defined process control. It allows the team to adapt around challenges.

The work is done in very short iterations, not exceeding 30 days to mitigate risk against these complexities and uncertainties. Traditional projects may run for years without phases, or phases may be several months. Agile practitioners feel that this is far too long and far too many risks are involved.

Most Agile practices follow lean principles to eliminate waste and only build what is needed. Agile practitioners recognise upfront requirements normally lead to high volumes of waste; e.g. 64% of features are rarely or never used - Standish Group Research.

Most people don't get agile as it is hard. The reason it is hard is we have all been educated to work with defined processes and control these processes. Breaking this mindset to deal with and learn to manage complex projects using empirical process control takes a lot of energy and commitment. It has been proven to be a very reliable way to deal with software projects but needs the change.

I have done some pod-casts on project management and Scrum which highlights these differences in detail, you may want to use google to try find these.

  • Thanks Brett, makes sense. I'll check out some of the podcasts.
    – Agile PMO
    Commented Jul 31, 2013 at 13:11

Regardless of the mechanism to deliver (as per @Brett's answer) I suggest that the definition of a project be as simple as "a project is an activity which delivers measurable value to the organisation by either increasing revenue, reducing cost or improving efficiency".

Each project that you deliver should be easily quantifiable as to why you are doing it.


How Agile projects are different from Waterfall projects

To elaborate on what @Brett Maytom PST said on the differences side:

  1. Minimize project risk: If you have features that are high risk (any unique value proposition that has not been built before), you can schedule them early on to validate whether it is at all doable. If you determine that it is either not possible or too costly to build, you can rethink the project viability.

  2. Fast feedback: Agile projects produce "shippable feature increments" at the end of each sprint. So, you can deploy this and get business users to play with it, do usability testing and sign up beta customers to get early feedback. This gives you an opportunity to change direction or even abandon the project before pouring the full budgeted amount into the project. In waterfall projects, you get a shippable product only at the end of the actual project completion - which itself may be above budget and behind schedule.

  3. Value negotiation: When we do an estimation session, too often our Product Owner is surprised. Some things the PO thought would be hard, turn out to be a simple setting in the library that the developers opted to use. While others that look simple enough require extensive custom coding. Looking at the estimate, our PO may drop some features and lower prioritize others. In waterfall projects, once the requirements are written, it is carved in stone (subject to change control, which is painful).


In Project Management you deliver a Project while in Agile you deliver an Epic. Projects have a defined start and end date while Epics have Products with a defined acceptance or done criteria instead of a date.

IMO the term Project shouldn't be used in Agile. You should align the teams to use similar terms and rolls so that generally procedures and practices can be understood and agreed by all. However if you are looking for the equivalent term to Project in Agile it wold be Portfolio Epic or Epic.

I would recommend looking into Safe for Lean Enterprises to get a good broad understanding for how to align several teams and products under a common Portfolio Epic which aligns to the business.

Another point to consider is the perspective of a Project or Epic in Agile. It should be known that Teams do not work on Epics or Projects they work on Products which could be a feature or item(s). Directors (Product Managers) and senior management work at the Epic or Project level. When they look for the status of an Epic they would be interested in understanding how many features have been complete for a given Product. The actual Product Delivery Team may not have a view of the overall Epic but only the products and features they are delivering.

  • 2
    Hi demarkus, welcome to PM.SE! I believe the terminology and usage of Epic may vary a lot according to the team and it could lead to confusion depending on the audience - unless you have some sound references of Agile or Scrum authorities supporting your view. Hope this helps!
    – Tiago Cardoso
    Commented Oct 16, 2019 at 16:11
  • Welcome to PMSE! I think your first couple of paragraphs are objectively incorrect. Agile frameworks, methodologies, and non-technical practices are certainly "project management" within the scope of the project management profession, and "product development" (which is just one type of agile implementation) is absolutely a "project" within the generally-accepted definitions within the industry. Your use of "epic" also seems problematic, as agility doesn't require the user story format or impose arbitrary batch sizes, although there are certainly best practices.
    – Todd A. Jacobs
    Commented Oct 16, 2019 at 18:05
  • It's okay to have a unique take, but if you're going to deviate from accepted orthodoxy you're probably going to need to add some citations to avoid downvotes. Alternatively, if you're providing anecdotal information about what works for your team, just make that clear instead of presenting it as the One True Definition™ of agility. That's definitely more acceptable than offering non-standard definitions as universal ones. Hope that helps!
    – Todd A. Jacobs
    Commented Oct 16, 2019 at 18:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.