The transition to agile implementation methods is revolutionising 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 365, and previously Dynamics CRM, 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 how I produce a Dynamics 365 roadmap, a type of user story map, that I use to communicate our scope, timeline and costs to our stakeholders. I like them so much that I use them on every project and I recommend that you 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 365 project. Their goals will change, and 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 they want into a written document. Written languages aren’t sophisticated enough to capture the nuances of human desire.
So it’s impossible to estimate and plan a Dynamics 365 project using traditional estimation and planning techniques that rely on detailed, accurate requirements specifications. Our estimates and plans need to respond to change.
Dynamics 365 roadmaps: the next best alternative
Agile estimation and planning methods, such as the Dynamics 365 roadmap, are not perfect either. But I think they are better. Here’s why.
We keep our stakeholders' goals at the top of our minds and periodically update them to refocus our efforts towards achieving the best outcomes.
We capture requirements at just a barely sufficient level of detail to estimate them. We defer the details until later. This saves time because we don’t analyse requirements that might change or never get prioritised.
We plan just enough of the project to get a business case approved, and then plan just enough of the next release to start work. Planning is a useful exercise, but we recognise that the plans themselves are not a valuable deliverable.
How to estimate and plan a Dynamics 365 project
Here’s are the six steps I follow to estimate and plan my Dynamics 365 projects and produce a roadmap:
- Determine user roles and primary goals
- Describe epics user stories for each user role
- Estimate the epics
- Estimate the team’s velocity, project duration and costs
- Prioritize the epics into releases
- Examine the roadmap as a team
The group of people included in the estimating and planning must be familiar with the organisation and with Dynamics 365. Diverse experiences and ideas lead to better estimates and plans.
If you are a Microsoft Dynamics partner and don’t have access to your prospective client’s stakeholders during the procurement/pre-sales stage, you will have to rely on whatever information is provided in a request for proposal. Unfortunately, this will mean that your roadmap is less accurate than it could be - this is the side effect of the arms-length procurement process.
Let’s take a look in more detail at each step.
1. Determine user roles and primary goals
In this step, we categorise our users into user roles. A user role is a cohort of users that have common goals, interests, characteristics, requirements, and behaviours.
As well as Dynamics 365 users, you might have other stakeholders with system requirements, even if they are not primary users of Dynamics 365. These might include industry regulators, insurance companies, the board of directors, auditors, business partners, the IT department, or other systems that integrate with Dynamics 365.
As a group, brainstorm all the possible user roles you can think of. Then associate, organise and refine the candidate user roles into a final set of user roles for your Dynamics 365 project. For each user role, define some useful characteristics such as their primary goal, access mode and frequency, previous experience and so on. Depending on the size of your Dynamics 365 project you might have 5 to 25 user roles in your final set, sometimes with a simple hierarchy.
Here’s a user role map from a Dynamics 365 for Field Service project for a state parks service:
2. Describe epics stories for each user role
Jeff Patton’s user story mapping (affiliate) technique solves a common problem with Scrum’s product backlogs. A product backlog is a simple, prioritized list of all possible requirements. Looking at a typical backlog it’s not possible to know whether the backlog is complete and sufficiently serves all our stakeholders or covers all the necessary business processes.
A user story visualises what a user wants or needs from a system. In user story mapping, we describe our requirements following a business process using activities and tasks. When estimating and planning a Dynamics 365 project, I prefer just to capture our high-level requirements as epics without being concerned about business process activities and tasks.
An epic user story, or epic for short, represents a collection of related user stories. An example of an epic might be “Lead Qualification”, and it would represent a collection of smaller user stories about managing leads.
For each user role, brainstorm their high-level requirements as epics as a team. Keep going until you can’t think of any more epics. Then, just like you did for user roles, group, organize and refine your epics. Remove any duplicates and clarify ambiguous requirements.
There are usually between 10 and 100 epics in our initial user story map.
Here are the user roles and epics for the Parks Service project:
3. Estimate the epics
Unlike traditional project estimation where we decompose activities into tiny tasks and someone estimates the effort of each task, agile estimation relies on the collective experience of the project team to estimate the relative complexity of each epic in story points.
My teams play planning poker to estimate the relative complexity of each epic. Planning poker is a gamified estimation technique that a group can use to reach a consensus about the relative complexity of a set of requirements. To play, a group of Dynamics 365 practitioners discusses each epic, then lays down a numbered card representing their estimate of relative complexity for that epic. The players all reveal their estimates at the same time, then discuss divergent estimates and play again until a consensus is reached.
The numbers on the cards represent story points, an arbitrary unit of complexity. I recommend a modified Fibonacci scale: 13, 20, 40, 60, and 100 story points. Estimates smaller than 13 story points are probably user stories rather than epics. Epics higher than 100 story points probably need to be split into smaller epics.
Relative complexity means that a 20-point epic is half as complex, on average, as a 40-point epic. Complexity usually corresponds to the effort needed to implement a feature that satisfies the requirement but is adjusted for risk. One 40-point epic might require less estimated effort than another 40-point epic but the second one requires the evaluation and deployment of an integration platform the team has little experience using so it carries more risk.
Ensure your epics encompass all your requirements, functional and non-functional. Use separate epics for non-functional requirements such as system integration, data migration, and user training if this is work the project team will undertake.
If your average epic is 30 story points, then your user story map probably has 300 to 3,000 story points in total.
Here are our estimated epics for the Parks Service project:
4. Estimate the team’s velocity, project duration and costs
For your soon-to-be-launched project, envision the Dynamics 365 implementation team you’ll be able to muster. As a Microsoft partner, I also include the resources that I assume my customer will provide.
Here’s an example:
- Customer FTEs: Product Owner (1.0), Business Analyst (1.0), Data Analyst (1.0), Integration Architect (0.4), Change Manager (1.0), Acceptance Tester (1.0)
- Partner FTEs: Project Director (0.2), Scrum Master (1.0), Solution Architect (1.0), Integration Developer (1.0), Functional Consultant (2.0), Technical Consultant (1.0), System Tester (1.0)
Take one of your 20-point epics. As a group, estimate how many epics this project team could complete in a two-week period, a sprint. Complete means taking the epic from an idea all the way to production. Let’s imagine our project team can complete two 20-point epics in a sprint. Their velocity is 40 story points per sprint.
Divide the total number of story points in your user story map by your team’s estimated velocity to estimate the number of sprints in your project. If the total number of story points is 573 and our estimated velocity is 40 points per sprint, then it’ll take 15 sprints to implement all your epics (14.325 rounded up to 15).
Multiply the number of sprints by the sprint duration to estimate the duration. It’ll take 30 weeks to complete 15 two-week sprints.
Multiply the number of sprints by the estimated weekly running cost of the project team to estimate the total project cost. In our example, there are 12.6 FTEs with an average loaded rate of $100 per hour who charge 30 hours per week to our project so the total project cost is $1,134,000 (12.6FTEs x $100/hour x 30 hours/week/FTE x 30 weeks). You can use actual costs for known resources, predicted utilization rates, and other variables to arrive at more accurate estimates.
Finally, divide the total project cost by the total number of story points to arrive at the cost per story point. In our Field Services project, our average story point cost is $1,979 ($1,134,000 ÷573 story points).
5. Prioritise the epics into releases
In the final step, we group the epics into releases. You might choose to release into production at the end of every sprint or deploy the first release after six months followed by releases every two months after that. You’ll need to determine the pattern of releases that makes sense for your organisation.
The first release is our minimum viable product (MVP). The MVP includes the features that provide just enough value to replace whatever the users are currently using.
Subsequent releases deliver incremental value to those users or new features to new user roles.
Armed with the estimated average cost per story point we can estimate the cost of each epic. The cost of each epic is an important factor (along with business value) when trying to determine its priority in the release sequence.
At the end of this step, we have our first release map. It describes the epics grouped into releases and the estimated complexity of each epic, sprint and release.
6. Examine the Dynamics 365 roadmap as a team
Finally, combine all the elements together into a project plan that your project team can review and debate. Refine the plan by checking the roles and goals, reviewing the epics, challenging each other’s assumptions, testing what-if scenarios, and comparing your estimates to actual data from recent projects. It’s a lot more fun, and useful than sitting around a conference room table reading a detailed requirements specification.
Drawbacks of Dynamics 365 roadmaps for release planning
Working with user story maps for release planning isn’t perfect, and has some drawbacks we need to be aware of.
We might miss some user roles or epics.
Negation: Group collaboration and conversation produces user roles and epics that are more complete and better understood than typically found in a requirements specification. Less time is spent describing detailed requirements before they have been prioritized.
Our estimates of relative epic complexity and the project team’s velocity are subjective and could be inaccurate.
Negation: Run an initial project for four sprints to test our assumptions and estimates, make refinements, and produce a better release plan based on real project knowledge.
Our proposed project team might be significantly different in composition, size or experience from the actual project team.
Negation: The team’s estimated velocity and costs can be re-estimated once the actual project team is formed and recalibrated at the end of each sprint.
Not all stories in an epic have the same value.
Negation: Often new user stories emerge based on feedback from users as they gain an understanding of the early features. These new user stories are often relatively high priority and replace the low-value user stories that have been deferred.
With a Dynamics 365 roadmap, your stakeholders will be able to visualise your Dynamics 365 project's scope, timeline, resources and costs in a single, simple chart. Roadmaps can be produced in a couple of hours for small projects, and quickly updated after each release.
Compared to a traditional project plan's Gantt chart that relies on an accurate and complete requirements specification, a Dynamics 365 roadmap is much faster to produce and just as accurate.
Grab your copy of Jeff Paton's User Story Mapping (affiliate) book and get started today. Let me know how you go in the comments below.