MuleSoft Catalyst — Build a Detailed C4E Backlog

In the same way that a Product Owner would develop a Product backlog for an Agile team a Product Owner will need to develop a Product Backlog for the C4E. The initial question that I have been asked before is why a C4E would have a Product backlog? Surely the C4E has to concentrate on Governance and Evangelisation. Well, yes they are some of the key elements of the C4E but to answer the question as to why the C4E needs a Product backlog we need to go back to previous articles where I addressed the question of developing the C4E mission statement and charter. Now, in the mission statement and C4E charter we looked at the initial structure of the C4E, why the C4E was required and, importantly in this case who is accountable for its success. Well how do we assess what success means and how we measure that success? The development of a Product backlog allows us to define activities with SMART criteria and measurable goals to drive the MuleSoft implementation to the desired target state which was defined in the initial mission statement.

For those that may not be familiar with SMART criteria I will borrow the definition from the MuleSoft Catalyst documentation

• Specific: A goal should be specific (Who, What, Why).
• Measurable: A goal is measurable so that there is tangible evidence that the goal is met.
• Attainable: A goal should be achievable. The appropriate knowledge, skills, and abilities to achieve the goal should exist.
• Realistic: A goal should be realistically achieved, given available resources.
• Timely: A goal should be achievable within a given period of time.

Each organisation will need to determine their near term and longer-term objectives but the key objective will be to develop measurable objects across each period. So, let’s look at some of the possible C4E Goals that can be defined and measured.

An obvious goal that, in my view, needs to be one of the key benefits and goals of the C4E is to drive the reuse of the API’s that are being developed. An example of how this may be described would be:

• Objective: Drive the reuse of API’s throughout the organisation by developing design and development standards which, through the application of governance can ensure that API’s developed by the organisation are reusable where ever possible.
• Goal: The designs for all API’s are governed by standards that drive the reuse of API’s within the organisation. API’s that are being developed are evangelised to the IT and Business community such that all key roles within the organisation are aware of the API’s available for potential reuse.
• How measured: Report, on a rolling quarterly newsletter or Website, the number of API’s that have more than one client using them. The reuse figure should be shown to be increasing in each reporting period.
• Potential risk: The risk of API’s not being reused can be mitigated by ensuring the designs of API’s are examined for reusability and by evangelising the business value of each API across the business community.
• Core Value: Drive reuse
• Time: Report quarterly on an ongoing basis
• Objective: Decrease project delivery timescales by publishing a set of standard and reusable fragments such as Common Error Handler, Common Logging Fragment, Common Audit Fragment which can be used by developers within the business.
• Goal: AnyPoint Exchange should host a number of assets which may be fragments, connectors and templates which can be seen and reused.
• How measured: Report, on a rolling quarterly newsletter or Website, the number of assets that have been deployed to AnyPoint Exchange.
• Potential risk: There is probably no risk associated with this goal as it would be expected that, as the capability matures, the number of assets that can be developed and deployed would decline significantly.
• Core Value: Best Practice
• Time: Initially this may be reported in the quarterly newsletter and will be significant in maybe the first six month of operation. After this period this will probably decline and may be retired at some point.
• Objective: The C4E should promote training opportunities for development staff.
• Goal: Have 10 developers certify as “Integration Professionals” over the next 6 months.
• How measured: The C4E Leader will track the number and type of certifications obtained by the development staff.
• Potential risk: Due to limited resources and project time constraints, not every developer will have time to certify.
• Core Value: Enable resources
• Time: 6 months

These are just three examples to give you a flavour of the types of objectives that you could consider but it’s important to emphasise that each organisation will have a different structure to their C4E, will have different funding models and will have a different set of customers that they are bringing with them on the journey. Each C4E will also have a different timescale for developing and introducing their capability and therefor the Product Backlog will be focused on possibly widely varying timescales. Some may wish a slow initial burn followed by an accelerated introduction to Production use whilst some may have a very fast initial burst, may be initially supported by short-term third-party resources, with a launch into a slower, ongoing, development lifecycle.

Having defined your Objectives and measurement criteria you must now convert that into an actionable, prioritised backlog of activities which, the Catalyst Framework suggest is performed in a number of Sprints. Now, I would just point out two things here. Don’t get the term Sprint here confused with the pure SCRUM Agile definition of a Sprint. Pure SCRUM Agile normally recommends a development Sprint of between two and four weeks if you are looking at the SCRUM implementation. The activities you are looking at here are not purely development work and will require a longer period for initiation and completion. Again, the Catalyst Framework suggests Sprints of either six four weeks Sprints or 12 two-week Sprints over a 6-month period. Of course, depending on your circumstances this may be feasible and I would agree that each Sprint must have a defined Sprint Goal however I believe that you could also consider managing this activity using a Kanban board, using whichever tool you are familiar with, Excel Spreadsheet up to Atlassian JIRA. Both have their advantages and drawbacks so I will leave it up to you to decide how you manage this activity.

As you can see this is a relatively short examination of this part of the Playbook but that’s only because the definition the C4E backlog can be so varied that, however much I talked about what you can do and how you should do it, it will depend on so many variables I wouldn’t contribute much more benefits that the tips I have provided above.

I have to say that, apart from the definition of Design and Governance standards and the development of common assets, this is one of the most difficult aspects that I have undertaken in establishing and operating a C4E. I have been involved in what seemed like many hours of discussion about what tasks need to be included in the C4E backlog, how to measure benefits of the C4E tasks and how these translate to measuring benefits on the wider organisation.

Good luck with this activity! Next time I am going to look at setting up the Central Repository for sharing assets and, as a little cue, this will be looking at MuleSoft Exchange.