Feedback loops in agile methodologies allow you to effectively steer towards completion of your minimum viable product (MVP)
Starting development of a new application by building a so-called MVP (minimum viable product), is a natural choice to make when using an agile project methodology. I often get the impression that, however, MVP is wrongly interpreted as "maximum viable product", as it is both the users and IT that push for more and more features to be contained in a first release. Additionally, the viability of the resulting product also often turns out to be, well, questionable.
Less is more
Stakeholders often want their products to contain features that support them in handling every eventuality that might occur in daily business. They also place special emphasis on user interfaces and their appearance and are therefore less focused on the underlying functionality.
Of course, your stakeholders' perspective on their application should matter the most to your team, as only they know which features they really need and how much value those features deliver. In order to counterbalance stakeholders' tendency to overload applications with functionality and focus on its appearance, your team needs to let them experience their application from early on.
A good approach to obtaining this early feedback is to release a first, minimalistic version of your application to your stakeholders and to jointly continue developing the application with them based on their feedback. This first, minimalistic version (or Product Increment in a Scrum setting) is called minimum viable product.
The Purpose of Steering
Developing an MVP is hard work, as each new feature and adaptation needs to challenged in terms of its business value and necessity. Accordingly, developing an MVP in an iterative/agile project setting requires a lot of steering to keep your increments on course. I emphasised that an iterative/agile setting should be employed, as
short feedback loops not only allow for fast feedback to the value and quality of the delivered functionalities, but also to the efforts that have been made to implement them.
The latter are especially important as we want to obtain early feedback, which means that we should not squander any time.
Start with Organising Your Product Backlog
When compiling the Product Backlog for your MVP, always keep in mind that it should describe what your application should look like, not how it should be built. Additionally, make sure that your Product Backlog Items are sorted by their business value by a forced ranking, with the most valuable items at the top.
Assuming that you use User Stories to capture your stakeholders requirements, I recommend using Epics to group them. These Epics should again be sorted according to their business value and, ideally, arranged in a separate column. At the beginning of your iterative/agile project, your MVP should be described by your Epic Backlog, with a few sample User Stories having been deduced for mainly the purpose of estimation. Please read my blog post about Epics to find out more about their relationship to User Stories.
In consequence, you will have a Product Backlog that consists of an Epic Backlog that relates to a separate User Story Backlog (that will be elaborated and adapted over time), with both being ranked according to their business value in descending order. Your team's discussion and negotiations with your stakeholders have resulted in an MVP that is defined by a set of Epics. Make sure that you have agreed on some Epics not being in the scope of the MVP and therefore below the "MVP line" in your ranked Epic Backlog, as this helps your stakeholders understand what is considered to be outside of the MVP.
Additionally, at the beginning of the project, at least your Epics should have an estimation associated with them. In the following, I assume that this estimation will be in Story Points and that we are using the Scrum framework. Keep in mind that your User Stories detail your Epics and that their business value should, accordingly, reflect the one of the related Epic. This structure will prove to be key to the steering approach that I will outline in the following.
Steering Your Project Through Epics
Now, let us assume that in each iteration, your team will be able to complete the User Stories in your Sprint Backlog. Each User Story relates to an Epic and carries a Story Point estimate itself. In most Sprints, User Stories from several Epics are implemented, as your path towards the MVP typically includes implementing vertical prototypes for your Product Increments.
In consequence, for each Sprint, you can compile the amount of Story Points that your team has worked on each Epic and how much progress it has made in implementing each full Epic. When compiling the Release Burndown for your MVP over several Sprints, this leads to a clear picture that shows
which Epics you focused on in which Sprint (e.g. in the first few Sprints, your team focused on the "Login" and "Assign User Profile" Epics)
how much of your Velocity was spent developing which Epic (e.g. your team invested 8 Story Points out of a Velocity of 10 into the "Login" Epic in Sprint 1)
how your overall progress is in terms of your Release Burndown (will we finish the whole Product Backlog until the projected date?) and
in terms of each individual Epic (does the sum of Story Point estimates of the User Stories that have been implemented for an Epic so far correspond to the total estimate for the Epic?)
Especially the last point has proven to be helpful in previous projects, as we were able to anticipate additional efforts that needed to be made for certain Epics well in advance and could take corrective measures.
How Do You Become Entangled?
When using agile methodologies in your projects, it often makes sense to release a so-called MVP to your stakeholders early on. Your team can define this MVP through Epics and related User Stories. Iterative or agile implementation of the latter allows your team to continuously plan and track the current development focus and your overall progress, both at an MVP and Epic level.
How does this make your team become entangled? Through steering your project from your stakeholder's view, namely from the perspective of your Epics, you can always answer the question of what business value your Sprints an product increments delivered to whom and whether you can release your MVP to your stakeholders at the projected time.
Care to Know More?
Like the "La Farola" lighthouse in Málaga, Spain, your MVP (and the associated product vision) should act as a beacon to your team, towards which they should steer their development efforts. I highly recommend you to visit this city, preferrably outside the main holiday season, though :).
Would you also like to know more about this post's topic? If so, then please post your questions in the comments below and I will be answering them. If the subject of your question is a hot topic, then I will dedicate a post to it in the future.