I am in a group that is insisting the deliverable after MVP be called Phase 1. This is causing a lot of confusion across the program. Is this a common practice? Is there documentation that makes a recommendation on this one way or an other?

EDIT: Let me elaborate a little on the confusion. We have LOTS of meetings and email exchanges that go something like.

Andy: "MVP is going out in two weeks and will have feature X. Feature Y will be implemented in the next phase and will go out in one month."

Bob: "So Feature Y will be in the second phase, right?"

Andy: "No, Feature Y will be in Phase 1."

Bob: "So it's going out in 2 weeks?"

Andy: "No, it's going out in phase 1 in one month"

Bob: "I thought phase one was going out in 2 weeks"

Andy: "No, the first phase is MVP. It's going out in two weeks. The second phase is phase 1."

Andy: "So, phase 1 is the second phase?"

Bob: "Correct"

Andy: "Can't we just call MVP "Phase 1 (MVP)", and the second phase 'Phase 2' so the second phase is Phase 2 and not Phase 1?"

Bob: "No."

  • 2
    "This is causing a lot of confusion across the program" Why? – Sarov Feb 21 '20 at 18:52
  • 1
    It would help to understand the impact on the program; as stated, this seems to be merely a matter of opinion for which SE can offer no authoritative answer. If we understood the impact on the program, we might be able to link it to the project management discipline. – MCW Feb 21 '20 at 19:41
  • 1
    Naming should convey information within your organization. You can call it "Stage 73: Wombat" if it makes people feel better. What does your charter or project glossary have to say on the subject? – Todd A. Jacobs Feb 21 '20 at 19:44
  • Would it help if you think of "phase" as synonymous with "iteration"? That seems to be how it's being used here. – Llewellyn Feb 25 '20 at 20:13

For me, "MVP" = a feature deliverable vs. "Phase X" = program launch/release

Example: You're revamping the Checkout flow for an eCommerce site. This is generally a large cross-functional effort: front-end engineering, abstraction services, financial systems, etc. Each individual team is responsible to identify and build their MVP features, which can be done piecemeal (unless there are direct dependencies). "Phase One" would encompass each teams' feature MVPs to deliver the first iteration of your program's launch.


So basically MVP is about deliverable with particular value to a customer (A minimum viable product is a version of a product with just enough features to satisfy early customers and provide feedback for future product development).

As for the scope of work called "Phase 1" there are no mandatory obligations to be a version of a product. It could be just a preparation step (eg infrastructure setup) or any other sequence of work that drills down to some joint result you specified.

Edited according to author's change. Probably you need to add a glossary for the project you are involved and then make sure all required persons have shared understanding of it.


The term Phase is suggestive of a sequential, predictive ("waterfall") style delivery rather than agile. It's not unusual to find people thinking that way if they have limited experience of agile.

One potential risk seems to be that phases are perceived as a competing layer of backlog prioritisation. (e.g. "This thing is really important but it is in phase 2 so we can't prioritise it over phase 1 things"). Phases can also detract from successful iterative deliveries. No matter how many successful releases you have the ones deemed to be the "end of phase" releases may be seen as more critical and therefore harder to negotiate than others.

I have had more success labelling things as releases rather than phases because the term release seems to be better understood as a technical procedure rather than something tethered to a fixed scope.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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