Normalisation Views

In a previous blog I covered Flomatika’s Normalisation capability. It came about to address the need we saw to allow a) teams to define and work in a way that best suits their contexts, whilst b) allowing data-informed decisions to be made at scale, without needing to wade through the noise. You can read about it here.

In building this capability, we found additional uses that can be applied to understand across an infinite range of 'Views'. As long as there is a way to categorise in your work management system (whatever the method), we would be able to show the distribution, and how that has changed over time.

Here I want to list the different types of Views for you to consider. This is just the tip of the iceberg, but hopefully it’ll inspire you to think of what Views would be helpful in your context. What is it that is impacting your teams, and if you could categorise and visualise, you’ll be armed with the knowledge to take action.

Demand

We already talked about Normalised Demand in the previous blog. Being able to group multiple work item types together into common demands so that analysis can be conducted without needing to see each of the individual work item types.

Our recommended Normalised Demands are:

• Features
• Enhancements & Optimisations
• Enablers & Tech Debt
• Defects & Incidents
• Management Activities
• Risk & Compliance

This is useful in seeing how your teams are utilised across the different demands. Is expectation meeting reality? Are they working on the right things? You can then course correct, or find out what is the factor that is influencing your teams.

Class of Value

Are your teams customer centric? Do they have the right distribution of their work allocated towards Customer Demand? Are they optimised for value creation?

A view that we strongly recommend is Class of Value, which has three categorisations:

• Value Demand is something your customer finds of value and would be willing to pay for. A new feature, or enhancement would be an example of this.
• Failure Demand is failure to do something or do something right for the customer, which your team now needs to put effort into correcting. A bug/defect is the most common example.
• Non-Value Demand are the things you need to do to stay in business, but your customers typically don’t see direct value in. Examples include Technical Debt, Risk & Compliance, hiring to expand your team’s capability. 

You want to understand the ratio of these demands and look to maximise Value Demand whilst reducing the other two. Is there a spike in Failure Demand? Is there a quality issue that has surfaced? Is the team spending too much of their efforts towards Non Value Demand? Perhaps it is the right time to tackle those technical debt we had delayed for so long.

A common way to categorise these that we have seen can be as simple as via work item types. A bug or defect is Failure Demand. Story is Value Demand. Task is Non Value Demand.

Class of Service

If your teams have adopted Kanban, it’s like they are using Class of Services to help them describe how a work item should be treated through a series of policies. Typically the categories are:

• Expedite
• Standard
• Fixed Date
• Intangible

Viewing the distribution can show you a lot of insights. If a team normally has 5% of their capacity working on Expedites, then you see a spike of 40-50%, it’s a sign that something has happened, and it’s not business as usual. Are the teams working in a state of urgency? If you spot it in Upcoming Work, then potentially you're seeing an early warning.

We’ve seen teams categorise these simply as using a custom field. Others might use Priority or Severity to represent the Classes of Service. Flomatika can support all of these, but also several of these simultaneously. Different teams may define these differently and we need to be able to support them.

Value Area

It’s worth tracking to see where the demands on your teams are originating from. Depending on your context, this can vary widely. As an example:

• Customer: Requests directly from your customers.
• Business: Requests from your internal business. You may even be more distinctive and split them further as 'Sales' and 'Marketing'.
• Architecture: Requests from your architecture team to ensure the longevity of your platform, or to support that new shiny feature.
• Infrastructure: Requests to keep your platform going. Time to install that new server, or expand your AWS infrastructure due to the increase of users.

Is there a balance allocation across those areas? Are there any areas that are getting neglected? Or is one area taking up all the available capacity? Perhaps we need to set targets for each area to assist the team in what the expected balance should be.

We’ve seen teams categorise this using custom fields. We’ve also witnessed more sophisticated rules, such as using a property on the parent the work item is a child of (eg a custom field on the Epic).

Build versus Run

A common View we are seeing Enterprises are interested how their investments is being allocated is:

• Build: Expanding the functionality of the platform, such as introducing new features
• Run: The operational work that needs to be done to 'keep the lights' on for the platform 

Typically you see the desire to maximise Build (Capex) over Run (Opex). Keep the operational investment low and focus on getting value to your customers. Visualising this will assist in understanding where your investments are going to, and if any actions need to take place to shift the distribution.

We’ve seen a few ways these can be categorised. By Work Item Type, and also by the Epic parent. You could even use Value Areas to classify between Build vs Run.

Defects Discovered In

Another view we’ve seen Enterprises keen on is where the defects are being discovered. Specifically which environment. Finding defects in the Dev environment is good, as it’s cheaper to fix. Discovering them in Production is more expensive to fix, not taking into account any reputational damage. As an example it might look something like:

• Dev
• SIT
• UAT/BVT
• Production

This is extremely helpful to visualise when you are aiming to “shift left” with quality. To be able to see the trend moving in the correct direction.

Categorising this may involve manually setting a value in a custom field. We’ve also seen enterprises using different work item types for where the defect was discovered.

Planned versus Unplanned

A common theme we’ve seen Enterprises want to visualise is understanding the proportion of work that is planned versus unplanned (typically in an environment where there is a large amount of interruptions to the original plan). 

• Planned
• Unplanned

Typically there is already a suspicion of a common pattern that is disrupting the teams, and visualising the proportion helps quantify the impact and create the supporting data to put some actions into place.

We’ve seen teams categorised by work item types, but also through a custom field (manually marking the unplanned work).

Actionable Insights

A number of these views we strongly recommend to make sense of what is happening at scale (Normalised Demands), and to drive a more customer-centric focus for your teams (Class of Value). The others will be useful depending on your context. This list is just the tip of the iceberg. No doubt you’ll be able to come up with other views that will be useful to see the distribution, and how it changes overtime. If you have a hypothesis, find a way to categorise in your work management system, then visualise through a view within Flomatika. Hopefully this will lead to understanding your delivery better, and being able to come up with actions to either tackle the root causes, or drive behaviours in the correct direction.

Learn More

Other blogs you might find of interest:

• Make sense of what is happening at scale 
• 5 metrics you probably haven't thought about
• 5 more metrics to help assess the health of your delivery