Whether you’re hitting a certain age, reached a goal, or completed a deliverable, you’re likely familiar with what a milestone is. Unless you’re living under a rock. Let’s assume you’re not and explain how Agile Milestones work.
The Misconception of Agile Milestones
You may read a lot of articles that talk about Agile Milestones in the same way they discuss traditional marketing or business milestones. But, the truth is, Agile Milestones are quite different.
A good starting point is to think about actual milestones–markers on the side of a road that tell you how far you’ve traveled or what the distance to the next town is. You can only get to the next town once you’ve passed all the milestones on the road.
Project management can be modeled in the same way. Any project of large enough scope can be functionally decomposed into a set of sub-projects each solving a problem and adding value. Subprojects can be broken down further into sub-sub-projects, and so on. The idea, of course, is that once you concatenate all the completed sub-sub-projects, you’ll have a working product ready for market.
According to the traditional rubric, delivering a product is like walking down a road. There’s a set plan that is designated to take some predetermined amount of time and there are concrete milestones that must be achieved on the way to get there. Everybody knows what the path looks like. It’s just a matter of walking down the path (i.e., doing the work).
This is not a good way to model Agile Milestones.
So… What are they?
Milestones in Scrum look different because the way to achieve a Product Goal in Scrum looks different. The model of a pre-built road of determinate length giving you a straightforward route to your goal simply doesn’t hold… unless nothing changes and your plan was 100% correct to start.
Scrum is fast-moving. It’s responsive to changing needs and empirical discoveries. It focuses less on a predetermined plan but is instead a set of strategies and tactics that can reliably, flexibly get you where you need to go with or without a plan.
So, in Scrum, it’s more like you’re building the road as you come to understand the landscape more fully and how that road will be used. Actually, it’s more like you’re building multiple overlapping roads that begin to connect in unexpected ways to reveal the topography and get you to your destination more quickly. Sometimes you might even choose not to use a road at all and take a flying car…I really did love Back to the Future.
Maybe the road analogy has reached its breaking point.
How are they used?
While Agile Milestones are not like your typical business milestones they are no less important. You just have to know how to conceptualize and categorize them.
Scrum is helpful here as there are concrete examples of milestone-like things in the Scrum Guide. A Product Goal is the target that a Scrum Team is working toward. A Product Goal is achieved by multiple Sprints. Each Sprint has a Sprint Goal as an objective. Increments are smaller items still. A Sprint may contain multiple Increments, and really should.
It seems natural to treat each of these commitments as something like a milestone toward the delivery of a functional product. You reach the Product Goal only by achieving several Sprint Goals and Increments along the way. Those are your milestones.
Again, though, it would be folly to suppose that these kinds of milestones are clear and predictable targets along a linear, predetermined path that you know beforehand. That’s just not how it works. Instead, Agile Milestones would basically be problems solved and the solutions are now usable. This helps determine the landscape, presenting more problems in need of solutions and constraining the fastest way through that landscape toward the goal.
Milestones are critical to achieving a Product Goal. But they’re difficult to predict until you’ve actually begun work on the project.
Having In-House Help
The ins and outs of Agile transformation within an organization are complex. Questions about how traditional ideas in business map onto an Agile perspective naturally arise, and the answers may be far from obvious.
That’s why you need experts to help guide you. Responsive Advisors starts with education. Our experts are skilled at building organizational awareness of Agile principles and how those principles get turned into action.
We also understand that Agile transformation doesn’t occur overnight. Getting an organization and its people to understand and embrace new and complex concepts takes time, desire, familiarity, and practice.
Agile transformation itself cannot be achieved by walking down a predetermined road, replete with regular milestones that mark progress in an orderly and predictable way. Responsive Advisors knows that agile adoption often takes circuitous and unexpected trajectories, but we also recognize the destination when we see it. Let us help take you there.
Tagged with: