Sprint Management for Dynamics 365 Projects

In this article, we will observe the sprint management and tasks associated with Dynamics implementation.

Dynamics 365 project execution might be a challenge. Managing scope and timelines, ensuring quality deliverables, organizing acceptance testing, and actual deployments require precise procedures to keep them on track.

We have gone through a lot of projects and come up with several tactics to manage Dynamics 365 implementations, and I would like to share one of them in this video.

Each team size and structure have different challenges. Also, the project type might have an effect since it can be ISV vertical solution preparation or end customer implementation project, or both.

In this particular article, I will talk about a mid-size implementation project with roughly 1 to 15 hundred users and 8 to 30 people in the project team. I will be also publishing other recommendations for such team sizes and management principles for other project types and structures.

The most common problems

We concluded that the 3-week time term was the best sprint duration for such teams. 2 weeks is too little to do the required regression testing, and 3 weeks is a minimum duration to ensure quality deliverables.

I would not go with longer sprint/release cycles because speed is a very significant part of Dynamics 365 implementation projects' value.

We start a sprint with the previously prepared scope.

The technical team works on it for the first 2 weeks, until those features are deployed for stabilization.

The features are tested as they are developed by all interested parties. Three days before release, features should be finalized and deployed to a Staging environment for regression testing.

During the same 2 weeks, product owners work on requirements documentation for the next sprint.

After release stabilization is started, the technical team addresses efforts to the technical dept or next release tasks depending on the priority, while QA and management teams prepare the required documentation and execute final release testing and regression testing. At the same time, the next sprint tasks are estimated.

On Monday the release day, we finalize the deployment plan, release notes, and actual build. Normally, we do release on Monday out of business hours to ensure team availability for emergencies the next days. This, of course, can be different depending on business operation hours for a particular project. We execute smoke testing and basic functional testing right after release deployment.

The next day after release, we do sprint closure and retrospective/planning meetings.

Each Friday we arrange management meetings to track sprint progress, check if any adjustments are needed, and whether things are as scheduled.

This is a quick overview of our approach to the sprint schedule that we use in projects already rolled out. In case your project is not yet rolled out – the stabilization & deployment release phases might be reduced to 1-2 days without regression testing.

I hope this article about sprint management in UDS Systems will be useful. However, if you have any questions about Dynamics 365, you are always welcome to contact us or book a call.