The transition to agile estimating and planning for Dynamics 365 or CRM 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.
However, the Scrum framework doesn’t provide any methods for estimating the size of Dynamics 365 projects or planning what to deliver in each release.
How to Estimate and Plan the Dynamics 365 Project
Here’s are the 6 steps I follow to estimate and plan the Dynamics 365 projects.
- 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 total release plan as a team
The group of people included in the estimating and planning must be familiar with the organization and with Dynamics 365. Diverse the experiences and ideas lead to better estimates and plans. If Dynamics 365 practitioners don’t have access to the prospective client’s stakeholders during the procurement (pre-sales) stage, they have to rely on whatever information is provided in a request for proposal, leading to less accurate output.
Determine user roles and primary goals
In this step, we categorize our users into user roles. A user role is a cohort of users that have common goals, interests, characteristics, requirements, and behaviors.
As well as 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 the group, brainstorm all the possible user roles you can think of. Then associate, organize and refine the candidate user roles into a final set of user roles for your Dynamics 365 project. For each user role, define some helpful characteristics such as their primary goal, access mode, and the frequency, previous experience and so on. Depending on the size of the Dynamics 365 project you might have 5 to 25 user roles in your final set, sometimes with the simple hierarchy.
Here’s the user role map from the Dynamics 365 for Field Service project for the state parks service:
Describe epics stories for each user role
The product backlog is the simple, prioritized list of all possible requirements. Looking at the 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.
In the user story mapping, we describe our requirements following the business process using activities and tasks. When estimating and planning a Microsoft Dynamics 365 project, I prefer just to capture our high-level requirements as epics without being concerned about business process activities and tasks.
A user story is intended to describe what a user wants or needs from a system. The epic user story, or epic for short, represents the collection of related user stories. The example of the epic might be “Lead Qualification”, and it would represent the collection of smaller user stories about managing leads.
For each user role, brainstorm their high-level requirements as the epics as the team. Keep going until you can’t think of any more epics. Then, just like you did for the user roles, group, organize and refine your epics. Remove any duplicates and clarify ambiguous requirements.
There are usually 10 to 100 epics in our initial user story map.
Here are the user roles and epics for the Parks Service project:
Estimate the Epics
Unlike traditional project estimation where we decompose activities into tiny tasks and someone estimates the effort of each task, Agile estimating and planning for Dynamics 365 or CRM relies on the collective experience of a 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 and every epic. Planning poker is the gamified estimation technique that the group can use to reach a consensus about the relative complexity of a set of requirements. To play, the group of the Dynamics 365 practitioners discusses each epic, then lays down the numbered card representing their estimate of the relative complexity for that epic. The players all reveal their estimates at the same time, then discuss divergent estimates and play again until the consensus is reached.
The numbers on the cards represent the story points, the arbitrary unit of complexity. I recommend the modified Fibonacci scale: 13, 20, 40, 60, and 100 story points. Estimates the smaller than 13 story points are probably user stories rather than the epics. Epics higher than 100 story points probably need to be split into the smaller epics.
Relative complexity means that the 20-point epic is half as complex, on average, as the 40-point epic. Complexity corresponds to the effort needed to implement the feature that satisfies the requirement but is adjusted for risk. One 40-point epic might require less estimated effort than other 40-point epic but the 2nd one requires the evaluation and the 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 the system integration, data migration, and the user training if this is work a project team will undertake.
If your average epic is 30 story points, then the user story map probably has 300 to 3,000 story points in total.
Here are our estimated epics for the Parks Service project:
Estimate the team’s velocity, project duration, and costs
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 the group, estimate how many epics this project team could complete in a two-week period, a sprint. Complete means taking the epic from the idea all the way to the production. Let’s imagine our project team can complete two 20-point epics in the 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 the velocity to estimate the number of sprints in your project. If the total number of story points is 573 and our estimated the 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 time. It’ll take 30 weeks to complete 15 two-week sprints.
Multiply the number of sprints by the estimated weekly running cost of a project team to estimate 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, the predicted utilization rates, and another variable to arrive at more accurate estimates.
Finally, you can 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).
Prioritize the epics into releases
In the last step, we group the epics into releases. You might select 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 organization.
The 1st release is our minimum viable product. The MVP adds the features that give just enough value to replace whatever the users are currently using.
The subsequent releases deliver the incremental value to those users or new features to new user roles.
Armed with an estimated average cost per story point we can estimate the cost of each epic. The cost of each epic is the factor (along with business value) when trying to determine its priority in the release sequence.
At the last of this step, we have our 1st release map. It describes the epics grouped into releases an estimated complexity of each epic, sprint and release.
Debate the total release plan as a team
Finally, combine all the elements together into the project plan that the 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 helpful than sitting around the conference room table reading a detailed requirements specification.
Drawbacks of a user story map for release planning
Working with the user story maps for release the planning isn’t perfect, and has some drawbacks we need to be aware of.
|We might miss some user roles or epics.||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 the detailed requirements before they have been prioritized.|
|Our estimates of the relative epic complexity and the project team’s velocity are subjective and could be inaccurate.||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 not the same in the composition, size or experience from the actual project team.||The team’s estimated velocity and costs can be re-estimated once the actual project team is formed and re-calibrated at the end of each sprint.|
|As we start to implement Dynamics 365, we split epics up into smaller, implementable stories. But only some of those stories are high value and will be implemented in the next release. Others are lower value and will be deferred to a later release or indefinitely.||Often the new user stories emerge based on the feedback from users as they gain an understanding of the early features. These new user stories are often a relatively high priority and replace the low-value user’s stories that have been deferred.|