,
9 tweets,
2 min read
Read on Twitter
The notion of "release planning" has come up a couple times recently. Agile release planning can't work like the waterfall version because you don't have a full up-front definition of the product. Scope changes as you work, so you cannot estimate. "What's a mother to do?" 1/
There are two approaches. Let's start with the less desirable (but usually more acceptable to corroborate people who don't understand Agile) approach. 2/
Start by setting up a maximum-acceptable release time. You don't know exactly what you'll release at that time since you learn as you work. So, start by figuring out that the market actually wants what you're building by releasing a series of small experiments (MVPs). 3/
Then work collaboratively with your users to identify and build the critical capabilities first. That way, those critical parts are done long before your release date and there's no real risk any more. Always build the riskiest stuff first. 4/
Those critical capabilities are more than enough for your marketing department to get to work. Now, take the remainder of the time in your release timebox and use that to fill in the details. 5/
When the release date comes, you may or may not have all those details finished, but you'll definitely have a salable product. 6/
So much for the hide-bound-corporation approach. In an agile world, you really should be releasing incrementally---every week or so at minimum, not at some far-in-the-future date, so there's less need for planning. In this more-agile world, you don't have a release date. 7/
Instead, you have revenue! (which is *way* better) and customers. Use customer feedback to increase the revenue by identifying what's important. Use the size of the revenue stream to decided whether further improvements are worth it. 8/
Instead of a marketing plan built around guesswork, run occasional marketing campaigns around what you added over the past few months. Much less risk. Revenue and customers starts very early. Maybe long-term release plans aren't all that necessary, after all. 9/9
