Agile Milestone Criteria for Projects and Programs
Learn how to set up and define your milestones to make sure your Agile team is set up for success.
Join the DZone community and get the full member experience.Join For Free
You've got interdependencies across the organization for a given project or program to release a product. You can see demos. That's not the problem. You need enough insight or prediction to start the marketing campaign or to create training videos or product documentation. You need some kind of milestone criteria so you know you can complete the entire product.
Milestone criteria allow a specific milestone to occur before the product is totally done. Release criteria tells you when a product is done. Milestone criteria tell you if it's okay to start this piece of the product work.
I wrote about how to define release criteria for the software (or hardware) part of the product in Manage It!, Agile and Lean Program Management, and in Create Your Successful Agile Project.
The rest of the organization might need to write release criteria, too. You might not have a product without documentation tutorials or marketing.
And, sometimes, achieving the software release criteria triggers other work across the organization. If your marketing organization needs performance or reliability data, they need the software/hardware to be close to done, if not totally done. That creates a staging/phase approach to releasing the final product.
When people outside of technology use agile approaches, they can start their work before the product is done. But, they can't finish their work because they depend on a state of product done-ness.
Let's take the case of a marketing campaign. The organization starts the campaign before the product is ready. (Some, very rare organizations wait until the product is totally done before the marketing campaign starts. My experience is that more people start the campaign before the product is ready. That's because waiting to release the product costs money.)
Starting the marketing campaign is a milestone for the program. It needs milestone criteria.
If we use rolling wave planning with specific release criteria, we can create smaller milestones (maybe not inch-pebbles) we can assess every couple of weeks to a month-milestone criteria. The frequency of assessment depends on your overall program duration and how much of the campaign needs to occur before release.
Let's assume your overall program duration is about 12 months and the marketing campaign needs to start 3 months before product release.
Define Release Criteria
During Month 1, when you kick off the program, ask each department or project or program in the program to create their release criteria for the product. That's how you'll know when the entire product is done. You might need to integrate/reword some of those release criteria so they make sense.
However, you have interim milestones in the program, such as starting the marketing campaign. The marketing campaign requires the product be "done enough" to start. If you only have release criteria, you don't know if you can safely start the marketing campaign.
That "done enough" is your milestone criteria. This is where the various minimums can really help your program. You've probably finished your MVEs (Minimum Viable Experiment) by the time you want to start a marketing campaign. You might have finished your MVPs (Minimum Viable Product) for the various parts of the program, so you can see that the overall product is working. You might need some MMFs (Minimum Marketable Feature) to work with customers on their reaction to what you've got so far so you can use their reactions in the campaign.
Define Milestone Criteria
You might create milestone criteria for the marketing campaign that says something like this (these are all made up):
- Be able to take one credit card payment in Payments so you can show the entire user journey from signup through payment.
- Full integration with Financials package. No remaining features. (Because the risk of finishing is too high.)
- Be able to show a video of the Email Happy Path (you would have defined that) working in the product.
You might have more criteria.
Programs often need milestone criteria. That's because they're working across the organization and they have interdependencies for product delivery, not story finishing from a team. A given team or even the entire technical part of the program can't complete the entire product itself.
Don't wait until the milestone arrives. Start assessing the milestone criteria as soon as you create them.
Assess Milestone Criteria in a Rolling Wave
As with release criteria, milestone criteria are either done or not done. If you're part way to achieving them, they are not done yet. Do not start trying to assess percent complete. That's a losing game. The milestone criteria are not done.
However, assessing the milestone criteria on a regular and frequent basis helps focus people so they achieve those criteria.
For the year-long program as above, I would start assessing milestone criteria every month for the first six months. (Maybe five months. It depends on the risks.) I would definitely watch demos every week or two, to make sure we're getting closer to the milestone criteria.
At about the six-month mark, I might start assessing milestone criteria (as part of the general program risk assessment) every two weeks. Again, that focuses the various teams.
Learn Early if You Will Miss the Milestone Criteria
When you assess the milestone criteria on a regular basis, you might learn early that you will not meet the criteria by the date you want. That's okay.
Early knowledge of a delay? Wow, that's valuable knowledge.
If you know you can't start the marketing campaign when you want to, you might choose an alternative date. You might reassess the problems the product is supposed to solve. You might reassess the markets. You can create choices if you know about any delays.
Use Milestone Criteria in an Agile Way for an Agile Program
I recommended a monthly rolling wave to start with assessing your milestone criteria. Your program might need to reduce that wave if the program is shorter than a year. If you have a six-month program, I suggest biweekly assessment for the milestone criteria.
While you might solidify the criteria themselves, adapt the assessment process. When do you need to re-assess the criteria? What else needs to happen in the program? Use a flow-based approach to your Agile and Lean Roadmaps to help everyone see what's happening in the program.
Milestone criteria aren't the only answer. However, I've used these in this way for years, and they've worked for me. Let me know how they work for you.
Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.