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 …