Azure DevOps Delivery Plans
Designing projects is challenging, which is probably a big reason why some people don’t even try. But just because something is difficult doesn’t mean it isn’t worth doing. Sometimes the most valuable things we do are difficult, and often the value in software development is in the difficult parts.
Designing projects has a few obvious benefits. First, having a sequence for the work allows you to identify interdependencies between the workpieces (e.g., “Does A need to be done before A?”). Second, designing projects enables you to make better estimates, and estimates based on completion by a specific date are better more realistic. Another big advantage of a project design is that it paints a picture for everyone of what the project will look like.
The difficulty in designing projects is that it requires a lot of thinking. And that requires focus time when we can think critically about dependencies, sequencing, resourcing, and how it all impacts our estimates. But it is better when this happens intentionally than by accident.
We typically use Microsoft Project to do this design. But Azure DevOps has a new feature called Delivery Plans, and I used Delivery Plans on a recent project design.
Delivery Plans in Azure DevOps is a great solution because it lives with our actual tasks instead of being a separate tool (like Microsoft Project). When you have a separate tool, it becomes one more thing people have to remember, and it might not be easily shareable (which can reduce its visibility to everyone).
To create a delivery plan in DevOps, click on “Delivery Plans” on the left menu and click “New Plan”.
Delivery plans need a name and a description. But you also must decide why types of work items will appear in the plan. You can select Epics, Features, or Stories.
Once you have your delivery plan, you need to create some features (or whatever you show in your plan; I selected Features). Creating these work items in DevOps is easy, and there are various ways to create them.
Once you have your features, you can start laying them out on the calendar. This is where I felt Delivery Plans really fell down. Laying features out onto a calendar was painful, and the UI felt half-baked. And I am not talking just about polish. It really felt awkward trying to get features to cross multiple iterations. Delivery Plans is really close to providing the ability to design out a project.
But at the end of the day, the calendar worked. As of this writing, I think the UI needs a lot of work.
I will follow the progress of Delivery Plans. While they are a long way from being polished, this tool has a lot of potential.
