7. Estimated End Date (MVP)
MVP? Is this one of those new texting things those crazy kids are doing LOL? No silly. It’s not Most Valuable Player, Most Valuable Primate (this is real), Mitral Valve Prolapse, and it’s certainly not Montel Vontavious Porter. I guess the best thing to do is describe it, and then we can talk about the letters.
The big idea is to figure out what problem you are trying to solve, develop the minimum product that solves all or part of the problem, and release it to users. In other words, when some value to the user has been achieved, release it. That doesn’t mean you’re going to throw junk at the customer, it means the moment you have something valuable that solves the problem you intended to solve. No gold plating, no cup holders, just raw problem solving stuff. Hence the name...wait for it...here it comes...Minimum Viable Product or MVP. The important word here is “viable.”
The example I like to use is Gmail. Remember when it first came out? It looked like this:
It didn’t have all the bells and whistles we see now, but it was enough to give value to users. There were already web based email tools out, but Google had a different strategy. Try out this new threaded paradigm and see if it catches on.
Why do we do this? Well, we want to get the product in the hands of users as soon as possible so that we can learn. We can validate rather quickly if we built the right thing for our customer and our users. Google did just this. They let it out and started to learn. If you look at where it was and where it is now, it’s pretty clear they learned a few things. As a side effect in business, first to market often wins. So even if the whole product isn’t done you can get it in the market, put your flag on it and declare “first.”
The Problem/Trap
So when we ask for an estimate of MVP, this isn’t a hammer we use to tell our customers, “you only get this much.” Instead, we want to drive them to create some tangible value as soon as possible so that we can get it in the hands of users. It is a great artifact for a discussion with the Product Owner to determine how many features need to be working before the product has hit MVP. Please don’t use it as a hammer. It’s really not. It doesn’t mean we’re stopping the project there. It would be downright SILLY to stop unless we have learned, after it was released, that MVP really solved enough of the problem that doing any more work would add little more value. It’s the point we feel we can release the product into the wild, let the users kick the tires on it and start making course corrections. By using the “hammer” we are promoting a bad behavior that will push customers away from our value of collaboration and more toward negotiation.
An example of the MVP for a mythical project can be found in the “Burn-up” charts below.
As you can see, dates are on the horizontal axis and points are on the vertical axis. This is getting slightly ahead but put simply, teams break up the project into small chunks of work. They then estimate the chunks of work using a point system. The magenta colored dotted line represents the number of points completed to get to MVP. In this case, MVP will be hit when the team has completed approximately 120 points worth of work. The estimate is “bracketed” by the best case scenario, the green line, and the worst case scenario, the red line. The likely case is in yellow. In the example above, you can see that in the best case, based on the amount of work the team gets done when they are at their best, they will finish on 2/24/2014. The picture below shows the worst case. This slower rate completion could be due to lower team strength, meaning people are sick or on vacation. It could also mean there is rework, the team is juggling or context switching, or various other delay causing problems. For this fake project, the worst case happens on 3/17/2014. So now we have effectively bracketed the dates that we think the project will reach MVP. It will be between 2/24/2014 and 3/17/2014.
In this final burn-up chart, we can see the average case denoted by the yellow line. This is an average of the points done in the worst and best cases. We should expect that if everything keeps moving as it has, that the project will reach MVP near the date in yellow, 3/3/2014.
That’s all there is to it. We’re taking the arbitrarituousness (hah) out of picking dates. In some cases there will be deadlines. It’s ok, we just have to plan accordingly. When we set artificial or real deadlines the Product Owner needs to know that it will affect the number of points that can be completed and thus the number of features will have to change. Next time we’ll talk about the Actual End Date.
0 comments :
Post a Comment