MVP v. Phase 1 terminology

Question

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."

Answer 1

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.

Answer 2

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.

Answer 3

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.