Find the MVP - Write BIG, deliver small

Posted on October 17, 2014 — in

So it happened again … A couple days after planning, and development raises an issue on a story that will impede the delivery of a feature. As a product owner what do you do? Stop work on the whole feature, retool the stories, and try to explain to the boss that something's going to slip? Most of the time that's not necessary. It's the definition of why we're agile.

I actually enjoy it when this happens. Development tries to play "stump the product guy" — OK, maybe they don't, but that's how it feels. Situations like this force product owners to be innovative, think about things differently, and come up with solutions. So, when a story is impeded, ask yourself (or development) a few questions.

1. Is there an alternative way to get this story done that won't stop work?

I know it seems pretty basic, but sometimes we just get too close to the story. We can't see it being done any other way. This may actually be a symptom of a larger problem where a story veers into implementation. If this is happening often, then you may need to rethink how your stories are written. I use a few story writing techniques to avoid this, but it still pops up from time-to-time. The easy answer is to ask development how they would deliver the functionality.

2. Is something missing from the feature?

Sometimes we ask for things to be done with information that doesn't exist, or it exists in a way that doesn't allow the functionality. If we've gone through the previous step without a resolution, then we may need write additional stories or chores to solve the original problem. Be warned though, we're charting into dangerous territory when this happens. Introducing unintended creep into a feature can blow out our expected delivery dates. Which takes us to my final point.

3. Is the feature really necessary, or necessary now?

This is the all important question. Do we really need to deliver this feature for a successful launch? We should be asking ourselves this often, not only when a story comes up as an impediment. We should ask it when we think we're done documenting the stories in an epic; when the stories span multiple iterations in the backlog; when the epic gets too big to justify. We should ask it before that marathon planning meeting where the stories are estimated. In a lot of cases the answer is no, especially when we consider if it's "necessary now".

We should strive for the minimum viable product (MVP) when introducing a new feature. Always. I know we've done our research, talked with our customers, done our competitive analysis, SWOP charts, revenue projections, etc., etc., et cetera. But the data we get from people actually using our new feature, does something amazing. It changes assumptions into actionable intelligence. I'm not suggesting that we throw out the stories that aren't necessary for the MVP, or that we should limit ourselves when documenting a feature. On the contrary, the details often inform the core of a feature, and we don't want to lose that. So document BIG, but deliver small.

I've been refining this process for the past couple of years. One area where I was having difficulty was conveying delivery expectations for the core feature set, and date(s) of the additional features. Dash of Agile is great for keeping everyone aware of when an epic will be done, but not great for showing multiple delivery dates for parts of epics ... until now. Dash of Agile now supports multiple labels when defining a feature. Now you can choose the base label, and then add one or more additional labels when adding a feature to the dashboard. All stories in Pivotal Tracker that match the combination of labels will be included in the feature.

Here's the process that I use —

First, I write my epic. I document everything that I know (or assume I know) that will make this new feature be a hit with my customers. Pivotal Tracker makes writing epics a cinch by letting me add new stories from the epic card. Every story that I write this way is automatically tagged with the epic label.

Add a story to an epic

Next, I take a look at my stories and I select the "necessary now" ones. When you have multiple stories selected, the top menu in Pivotal Tracker changes and allows you to perform an action on the selected stories. The second option allows you to add or remove labels on the selected stories. I add a "v1" label to my MVP stories, and deselect them.

Last, I select the features that should be delivered after the MVP, and I add a "v2" label. I repeat the process until all my epic stories are tagged with an additional label that informs the order in which they’ll be delivered.

Add a story to an epic

In Dash of Agile, I leave the "Automatically create Features from Epics" option selected because I want to track the overall delivery of the epic. I then add a new feature, picking the epic label and the "v1" label and call that my “Feature — MVP”. I repeat the process for additional versions of the feature. Now my dashboard will show all feature deliverables in the order that they'll be launched. This makes it easy for everyone to stay up-to-date on the main feature launch and future updates.

So, how are you handling the inevitable story impediments? Are you limiting epics to minimum viable products? Let's discuss!

comments powered by Disqus