The Power of Milestones

In this article I wanted to talk about a concept that seems to be increasingly missing in product teams.

I find too many product teams just pounding away on the product backlog, story by story.  Too many members of the team don’t really know how and why the stories are even there, they don’t understand the customer pain they’re trying to address, and they especially don’t understand how their work on this particular item helps to move the needle for their business.

Usually the product manager somehow tries to explain the context for each story, but the granularity is so small that it’s hard and you can just see the team’s eyes glaze over.  Sometimes product managers or delivery managers react to this perceived complacency by trying to instill a sense of urgency by manufacturing a deadline.

We all know how averse many Agile teams are to commitments and dates, and I am definitely not talking about someone creating an old style schedule.

Now, many teams try to align their sprints with business value, and I like this.  However, two trends have caused this to happen much less frequently.  First, many teams have moved to Kanban or at least to much more frequent releases than every two weeks.  This has many advantages but can easily cause the team to lose context.  Second, many of the most important objectives really don’t line up with a sprint; they might require several sprints.  Moreover, the whole concept of “releases” just isn’t what it used to be.  A release used to be an event; something to rally around.  But now we do releases every day, which again is a very good thing, but we lost the focus and sense of purpose that was attached to a release.

The concept that I’m talking here about here, and that I encourage teams to emphasize, is the power of milestonesrepresenting actual value.  Things that matter to the business.  Things that represent outcome not just output.  Milestones aren’t about dates; in fact most don’t have an associated date.  Rather, they are about results.

Some examples of what I mean may help.

One of my absolute favorite milestones is when we actually get an early reference customer live and referenceable.  This means that at least for this customer, they are able to use our product and get real value and are willing to tell others.  And then when we have our first set of customers live and referenceable we now have an especially significant milestone – we can dial up the sales force and go leverage these references (see Product Market Fit).

Or providing the set of functionality required to serve the needs of another type of user or persona.

Or hitting a target KPI goal.

Or delivering our mobile app on the Android platform.

Or getting a live-data prototype to the point where we can run an A/B test and learn whether these particular ideas actually work or not.

To be clear, reaching some artificial intermediate state like code complete or automated tests written is not what I mean my a meaningful milestone.

Hopefully you get the idea.

It is normally the Product Manager/Product Owner that defines these business relevant milestones and prioritizes them, and especially evangelizes them.  It is critical that every person on the team understands the meaning and importance of each milestone.  And delivering on these milestones is what we want to celebrate.

If you’re having trouble getting your team motivated and focused on meaningful work, I hope you’ll consider introducing the concept of results milestones to your team and your company.

In my next article I’m going to talk about one of my favorite techniques for significantly speeding up the delivery of a milestone.