I’ve been coaching several teams with a problem: they like to work in iterations. And, they have milestones that are not on a milestone boundary. What should they do? (I suggested flow and you should have heard their response. Well, maybe not.)
Here’s why people want these milestones:
- The team can’t deliver (for whatever reason) as continuous delivery.
- The PO (or someone else) wants to release that MVP or the entire feature set on a specific day. That release solves someone’s problem, which is why it’s a milestone.
Here’s an example: Imagine you work on a school-based product. You can’t change the grading part of the product in the middle of a grading period. However, you can change the grading part anytime after a grading period has ended and before the next one starts. Maybe you know that a potential customer is coming in for a big demo in three weeks. You want that new grading product as part of that demo. You work in two-week iterations, which is normally a good thing.
You might use continuous delivery for the other parts of the product, but not for the grading. You need to achieve this milestone and it’s not on an iteration boundary.
Here’s how I’ve managed this problem inside the team in the past. The team ranks the stories and works in rank order, finishing the features. The PO accepts the features and the team releases internally or with a flag to prevent customers from using the new functionality.
Keep the stories small. Just because the milestone needs it “all” does not mean the stories can be large.
The team can mark this work as “done” but the work is not released.
This board shows the done and not released work. Now the team knows what to do. This doesn’t solve the release at different times outside the iteration boundary. Here are some options:
For teams that finish work on feature sets on a regular basis, the team is done. But, what about teams that are new to agile and don’t finish small features every day?
The team creates a cadence of releasing every week. Every week, at some particular day or time, the team releases what is done. Yes, this is a weekly project release train.
One of my clients tried this. That’s when they discovered their PO was not available enough for fast feedback on stories.
They had been using a regular Scrum board with three columns: Ready, In Progress, and Done. The work kept piling up in the In Progress column. Then, when the PO finally had time to review the stories, he rejected over half. The team had been working in the dark.
The team created this board so they could see where the work was. As a side benefit, the PO could see when it was time for him to look at stories. (These two boards are in Create Your Successful Agile Project.)
Some teams using iterations do not have fully-completed features until the end of the iteration or past that time. That’s because they cannot deploy on their own. (If you have a program, I wrote about how to organize program teams to make sure you can deploy in Agile and Lean Program Management.)
If you can’t deploy as a team, make sure your board has as many prepare-to-deploy and deploy columns as you need. Work with the deployment people to create a weekly or biweekly cadence for your deployments. As a benefit, you’ll learn what everyone needs to do to make deployment faster and easier.
My rule-of-thumb is that if you have milestones to meet, consider using flow, not iterations. Increase your cadence of deployment so you can meet milestones.
| Reference: | Creating Milestones with Iteration-Based Agile from our JCG partner Johanna Rothman at the Managing Product Development blog. |
