As I dive into a new round of planning and discussions for our next project with the product management team and designers, I keep hearing, "This is MVP." No, they are not referring to Most Valuable Player, but rather Minimum Viable Product — the product that has just those core features that will still provide value to the customer. Unfortunately, this can sometimes lead to over-promising or large user stories. In the beginning, sometimes it feels like everything is MVP (until you start understanding the actual scope of a feature). Let's talk about a term my colleague, Trevor Akiyama, came up with: the MFP — Minimum Functional Product (the minimal set of things that actually works, as opposed to the MVP that stakeholders want).
Why do you need them?
Over the years, I have often seen one single user story that was more like an epic, simply because everything within the story was part of the MVP. What resulted was a user story that stayed open forever, with no way to test until all the pieces that were dependent on each other were integrated. Now, what if we had broken down the user story into smaller pieces and found the MFP? We would have had clear, short, testable user stories. For teams trying to transition into the world of Continuous Delivery, testable stories are a MUST. By identifying your MFPs, you help your team keep stories small, and prioritize how to build (and therefore test) your product.
The Planning Games
Imagine you are starting your planning phase, and you get a story that is just too big. Your product manager wants it all. (I’m pretty sure this has happened on every project I’ve worked on since the beginning of time.) As an example, I work in education technology, so let’s take a look at building an online test. PM: For us to deliver tests, we need to have due dates, all of these question types, and grading. Me: OK... great. That is your MVP. But we need to break it down. Your user story is too big — it takes us through the entire workflow. PM: What do you mean? Me: If we keep the user story right now, we have to create a test, with the fields you want, add questions, be able to submit it as a student, grade it, and view those grades. Don't you think each of those things qualifies as its own story? PM: Hmmm, we can do that. So what is the smallest set that actually works? From the conversation above, I see a few things. (Please keep in mind, this is just an example — I am not listing everything under the sun here): User Story 1: Instructor can create a test. (MFP — Why? it is one of the most basic things I need to make this product functional.) User Story 2: Instructor can add a due date. User Story 3: Instructor can add an essay question. (MFP — Let's just call this the most essential question type; without a question on a test, what is the point?) User Story 4: Instructor can add a true/false question. (for arguments’ sake, let's just say this is not a critical question type, but it’s desired for delivery). User Story 5: Student can submit a test. (MFP — to make this functional at all, a student must be able to do this.) User Story 6: Instructor can grade a test (MFP). User Story 7: Student can view grade (MFP). Note that, while all are part of the MVP, not all are MFP. The stories that are MFP are the bare minimum experiences to get a functioning feature — but not necessarily deliverable to the client yet. The other stories can build upon the MFPs to create your MVP.
Watch out!
In the example above, if we chose not to break things down and identify the MFPs, we could have opened ourselves up to scope creep, as it's harder to identify hidden scenarios in such a large story. As a result, we would also have a hard time identifying all acceptance criteria, thereby deteriorating the quality (not to mention time to complete), and ultimately, the value to the client. And doesn't that just defeat the purpose of the MVP? It is so important to watch for the user stories that either need to be broken down, or start to show growth as design goes on, and therefore create more user stories to accommodate further clarification. Large user stories are not going to be sustainable in a continuous delivery world, and will revert you back to (gasp) waterfall life cycles.
Break it down
Establishing your MFP can help even more in determining what is in scope, and what has to be deferred. It helps drive conversations to identify what is critical (or not) for delivery, forcing people to think in smaller pieces. The smaller something is, the easier it is to estimate, plan, design tests, build, and deliver. Use your MFPs to drive your team to continuous delivery.
Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.
T: @aahunsberger L: https://www.linkedin.com/in/ashleyhunsberger
