I see a lot of MS Dynamics 365 implementations where the BPM in Lifecycle Services (LCS) is not used. They are running fine (at least that is what the clients are telling me). But in general, their implementation partner did not tell them all the benefits LCS has in store for them. Why should a partner bother to mention all the benefits Improvements on testing and user help experience does not result in more billable hours? So is your Business Process Modeler updated?
Using the BPM in combination with DevOps supports more streamlined and efficient implementation projects. By defining the processes in the BPM library; there is a generic structure for tracking the project requirements / user stories / tasks. The BPM hierarchy can be synchronized with DevOps – as a result the DevOps backlog and boards are populated with structured work items ready to be used by the project team.
In addition to tracking the progress of a project, the BPM and DevOps processes and work items can be used for automated testing (RSAT) and user documentation (online help recordings). Read more on these topics in our other blogs!
When defining the processes and work items it is important to understand how LCS and DevOps share the information. There are various approaches one can take regarding the level of detail to track in BPM vs DevOps.
Business Process Modeler
The BPM is a necessary evil – I must admit, it is a strange thing. Currently it is the only way to bring business processes, task recordings, automatic testing, and user documentation of Dynamics 365 together and re-use the information between the different areas. At the same time, it is not extremely user friendly when compared to for example DevOps.
recommendations
- The model name must be short, the name is reused everywhere later-on in DevOps, I always call it simply BPM, so later the titles of my epics, features and tasks start with [BPM]
- The existing BPM models from MS are too big and complex, no key user will ever be able to put the task recording on the correct place.
- Create your own BPM
- 2 layers
- The 3 layer is in additional point for adding the task recording. A BPM could be like below picture, the customer has 2 tasks recording on how to create a customer
The BPM can then be synchronized with DevOps – the above hierarchy will generate DevOps work items with type “Epic” and/or “Feature” based on the synchronization parameters.
Once the epics and features have been synchronized, it is possible to add Requirements per process node via the button “Add requirement” – the work item type of a requirement in DevOps is also defined in the synchronization settings of LCS and depend on the DevOps project process template.
All links to DevOps are visible in LCM on the BPM nodes, including the test cases. The below considerations are important when making the decisions regarding what type of work items to track in which application.
BPM and DEVOPS
How does it integrate
- The synchronization between LCS and DevOps is one-directional from LCS BPM to DevOps, as a result:
- Any updates made in DevOps will not be reflected in the BPM library
- All work items that need to be available in the BPM need to be created via BPM and synchronized to DevOps
- Business processes (epics, features) need to be created in BPM, not in DevOps
- The mapping between BPM and DevOps is done in LCS and the options available depend on the project template type used for the DevOps project:
- when “Agile”, a BPM requirement type will generate a work item with type “User story” in DevOps
- when “Scrum”, a BPM requirement type will generate a work items with the type “Task” in DevOps
- If the DevOps template is “Custom” – including when it is derived from Agile – a BPM requirement type will generate a work items with the type “Task” in DevOps
- Test cases are linked to BPM process nodes (epic/feature in DevOps), not the requirements (user story/task in DevOps), maximum one test case can be linked to one process
- The one-directional synchronization rule applies also here
- If the test case should have a link to the requirement / user story / task, this can be added manually in DevOps
The DevOps process templates can be defined via DevOps Organization setup screen. The standard process templates are pre-created (Basic, Agile, Scrum, CMMI) and can be extended (KANBAN below).
The process template must be linked to the DevOps project via project settings screen:
The synchronization settings between LCS and DevOps are configured via LCS project settings tab “Visual Studio Team Services”. The options available in this screen depend on the process template used for the selected project.
In case of Agile process template, it is possible to select “User story” in the column “VSTS work item type” for LCS work item sub-type “Requirement”:
In case of Custom process template, it is not possible to select “User story” in the column “VSTS work item type” for LCS work item sub-type “Requirement”. The only available options are “Task” and “Bug”:
For additional details regarding the different DevOps process templates and how these are intended to be uses please refer to the Microsoft documentation
Conclusion
Considering the usability of LCS BPM and DevOps and the synchronization limitations our recommendation is to use BPM for 2-3 levels of processes and use DevOps for tracking the user stories / requirements / tasks. With this approach, the end users and key users can add new user stories / requirements via DevOps and link them to the proper BPM nodes (features / epics) inside DevOps.
When a new process is added, this must first be created via LCS BPM and synchronized to DevOps to make it available as a parent on new user stories / requirements.
Good luck on your improved user experience!
Het bericht Is your Business Process Modeler updated? verscheen eerst op Kaya Consulting.