Agile estimating and planning for Microsoft Dynamics 365/CRM projects

The transition to agile implementation methods is revolutionizing enterprise software projects. Agile projects offer faster deployments, reduced costs, higher quality, more satisfied users and stakeholders, and more fun for the project teams involved compared to traditional, waterfall methods like Dynamics SureStep.

I've been using the Scrum framework to implement Microsoft Dynamics CRM, and now Dynamics 365, since 2009. However, the Scrum framework doesn't offer any techniques for estimating the size of Dynamics 365 projects or planning what to deliver in each release.

In this article, I'll outline the agile planning and estimating techniques that I use and I invite you to explore further and try them on your next Dynamics 365 project.

The Myth of the Perfect Requirements Specification

I became a CRM business analyst in 2002 and for ten years I was on a mission to write the perfect CRM requirements specification. I studied methods such as Unified Modeling Language, Rational Unified Process, and Business Process Modeling Notation. I obtained my Certification in Business Analysis from the British Computer Society in 2005. I learned techniques such as Riva role-activity diagrams, Cockburn's use cases, and interactive wireframes using Axure. But I never wrote the perfect requirements specification. Here's what I learned.

It's impossible. There's no such thing as the perfect requirements specification.

It's impossible for stakeholders to maintain a constant set of requirements within a constantly changing environment over the lifetime of a typical Dynamics project. Their goals will change, so will their software requirements.

It's impossible for users to faithfully express what they need from enterprise software until they've seen the system in action. They will change their minds after they begin to use it.

It's impossible for a business analyst to faithfully transcribe what a user says ...