Keeping Calm Whilst Troubleshooting Software Bugs

As a manager of a team of consultants, I no longer have my own configuration problems anymore, so troubleshooting is a theme that plays into every single working day.

When I started 10+ years ago, seeing an error would fill me with dread, sweat, and stress that I just couldn’t shake, and today I see technical bugs as a little bit of fun to try and solve the unknown! Some will think I’m strange, but everyone has their niche.

My thought process has changed dramatically over the years and it’s not something that you can teach, it’s all experience. I used to panic particularly about the reaction of everyone around me.

  • I’m an awful consultant.
  • I bet the client/end user is going to be so angry.
  • How do I tell people that something is wrong?!
  • What if I don’t know how to fix it?

Today it’s entirely different and it’s all about the tech, and here are just a couple of provocative sentences for to consider when troubleshooting technical issues to slow down the pace of thought and to focus on the outcome. I can assure you there is a good explanation!

100% pass rates during testing are terrible.

If test scripts produce a pass rate of 100% then it is very likely that we haven’t considered all of the possible paths that the end user may take, and we might have focussed on the happy path too much.

We want to break things during testing, as it means that they’ll be fixed or known about with recommended workarounds by the time the feature moves to the production environment with real users.

Taking a Power Platform example, when testing a requirement such as ‘Entering data into the Contact Table’, perhaps we should consider:

  • What happens if I upload instead of creating from the Form? Are all rules respected?
  • What happens if I create the Contact from another record, does the Form behave the same way as it would if I were creating the Contact standalone.
  • What if I create many versions of the same Contact to try and confuse the system? Does it change the way that the system behaves in other areas?

These tests may seem extreme, but remember, we can never guarantee that an end user will work in the way that the system is built, which often highlights the result of a potential gap between UI and UX.

There are some fantastic examples out there describing this difference which you can find online. Think of the glass bottle of ketchup that we place on its lid when it’s running out so that we can get every single last drop, and how we used to bang on the bottom of the bottle or use a knife to try and help the flow through the thinner neck at the top. It’s no coincidence that today’s bottles are plastic built and have the lid at the bottom, with a width the same across the entire length of the bottle, as well as a squeezy mechanism to help with flow. These are all features that were created because of user experience rather than user interface.

Another notable example I can also almost guarantee that everyone reading this post has been guilty of – The great corner-cutting mud patches that we find in parks or woodlands where two paths meet at a 90° angle. The paths always look nice, but we are built to try and be efficient, and watching someone follow the path in this case can often look unusual. In our local area we’ve had five new-build estates pop up and they all feature non-linear paths. I wonder why?!

Work out who’s to blame.

Wait what? I thought we were all on the same team here. You’re absolutely right, but there are so many parts to any software delivery that you really do need to identify which supplier of the technology is causing the issue.

One of the most interesting examples I saw of this recently was a scaling issue in a Power App that was being loaded through the Website tab in Teams (for good reason, it had an appended URL!). Out of context, the Power App would render fine with no issues functionality or cosmetically whatsoever, but then it occurred to me that this is a 4-level hierarchy of display settings!

  • The person accessing the app is using a desktop monitor with a resolution and scale.
  • Teams on the desktop also has its own scaling percentage.
  • The Website tab, just like web browsers, is mobile responsive.
  • The Power App also has its own scaling and ratios built in as well as orientation.

In this setting, we had control over the Website Tab configuration and the Power App configuration, but we can’t ask end users to use a specific monitor resolution and scale, nor can we change their Teams environment. Rather than ‘fixing’ the perceived issue, we have to work with it, and in this case the ‘fix’ that worked for us was the ‘Lock Aspect Ratio’ setting on the Power App’s Settings so that it rendered in the way that we wanted it to irrespective of other scaling factors that we can’t control.

Final Thought

Bugs will always occur in software delivery, we see it from every single software supplier in the world. So, let’s not be afraid of them and let’s tackle them head on and ask ourselves some thought provoking questions in the process!

Translating Unknowns into Tangible Requirements

For me, the most exciting part of a project is the challenge of figuring out exactly what a client is asking for based on a very short brief provided in an introductory call.

This challenge is increased in my industry when you move from Dynamics 365 based projects to pure Power Platform projects, because you move away from a functionally built system, to a set of tools that enable the capability. Not only do we now have to qualify the tool, but we also need to qualify the business process at an earlier stage than we typically used to, as well as the full data model.

For example, a “helpdesk replacement tool” screams Dynamics 365 Customer Service, and consultants in the industry typically understand the core operational processes before they speak to a customer. On the Power Platform, however, no two ‘self-serve chatbot’ projects would ever be the same, and there’s no functional process that you can align to this.

So how do we quantify projects with so many unknowns when we need to fully design the data model, the user interface, and the functional process? One way to start is to look for three themes:

  • Trends
  • Assumptions
  • Caveats

The first consideration I make is whether there are any repeatable components for any given high level requirement.

Whilst this doesn’t necessarily give us the full requirement ready to build, it does give us an idea of the size of the scope in contrast to a solution that is easier to estimate. Let’s take the idea of implementing a chat bot for a client on their website.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.

Within the industry I work in, we know that a configurable Power Virtual Agent for Teams solution that only uses Entities is relatively straight forward, and doesn’t require code. The interface used to build the solution is entirely controlled by Microsoft, so we also have confidence that it works! Let’s now put our original requirement into context by using known unknowns:

  • We know that the client cannot deploy this through Teams, but we don’t necessarily know exactly how to deploy it through a website that we don’t control just yet.
  • We are not being asked to build their website and we don’t know what their data source is, but we do know that we can take advantage of data and automation services that we can control to make this easier, perhaps Microsoft Dataverse with some sort of movement of data via Power Automate?

We now have broken down the requirement into tangible considerations and we can justify risk and complexity based on what we do know and what we can control, so we should factor this in to our estimate right from the beginning.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.


1. Power Virtual Agents for intelligent chatbot functionality.

2. Power Automate to drive dynamic data interactions between end user and data source.

3. Dataverse to assist with controlling data where necessary.


Next up, assumptions. We are often taught that making assumptions is a bad thing, and in most cases that is correct, but assumptions can be extremely powerful when defining a requirement if used correctly.

Taking our earlier example of a chatbot being deployed via a client’s website, we really don’t want to be developing the website in unfamiliar territory, nor do we want run into any bumps if their data source isn’t fit for purpose. For now, we can set assumptions against our requirement to portray what we would typically expect within the client’s landscape, and if any of these are found not to be true, then we can justify a change in direction for a requirement through a change of scope, estimate, and change request!

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.

1. Assumes that the client’s existing data model is fit for purpose, and if any changes should be made, the client will take responsibility for these.

2. Assumes that the solution can be deployed using a embedded HTML code snippet, as per Microsoft’s standard approach.


And last but not least, we have caveats. Clients may see these as the supplier creating ‘get out of jail free’ cards, but in reality, these are to ensure that everyone involved understands what should happen in the event that one of these factors occurs. Caveats are usually based on assumptions, but can extend further than this to cover typical project factors too.

As a website user, I want to be able to engage with a chatbot, so that I can easily find out store opening times and current stock levels.

1. If the data source should change after delivery, the client will be responsible for a change request for any errors that may occur with this solution if they wish to continue using the functionality.

2. If the client’s website cannot support HTML snippets for any given reason, the project may need to be delivered via a Power Apps Portal, which would incur extra cost to ensure the delivery is built to the correct standard.


When I describe this way of working with my team, I reference a phrase that may be familiar to some – It’s about the journey, not the destination. Imagine you have a 100 mile journey to make with no map functionality, digital or print. What would be your first move?

Success isn’t just the destination, or the solution in this case, it’s the route to it and the service provided along the way that counts. This continues to be a significant theme throughout the whole lifecycle of the project, and it can make or break the final engagement with the software.

The Power Of A Great User Story

For anyone that personally knows me, they will know that I am absolutely obsessed with getting User Stories right!

On the face of it, it may seem impossible to deliver part of a business process from one single sentence, but user stories are one of the best tools you can use, right from your initial engagement through to post go-live support as long as each part adds value.

What is a User Story?

User stories can help us to define a requirement for a business user or process that needs to be included within a project or product to ensure success. Generally speaking, user stories follow the following format:

As a [persona], I want to [achieve], so that I can [action].

That is all, one seemingly simple statement. Some may feel that writing user stories are a waste of time in an agile project, particularly as an agile project is supposed to deliver technical outputs quickly, however, user stories can actually speed up the turnaround time of the solution, providing that we pay particular and collaborative attention to it’s construction.

The Construction

Let’s take a look at what we want to achieve from each part of the User Story and how we can add value. As I am a Power Platform and Dynamics 365 Customer Engagement consulting manager, I’ll be using an example from Dynamics 365 Customer Service.

As a [persona],…

It would be easy to write “As a user…” here and be done, but this doesn’t tell us anything except that this isn’t an automated process.

Particularly in the Power Platform and Dynamics 365 space, the functionality and security model can span multiple applications, so perhaps we can describe the user and the way that they’re accessing the product or feature.

As a Customer Service Representative accessing the standard Customer Service Hub application,

From the above, we can understand that:

  • The user definitely needs a Dynamics 365 Customer Service license if existing licenses do not allow access.
  • The user is likely to use the standard Security Role provided due to the persona’s role.
  • The user is not expecting a tailored sitemap experience, as they will access the application through existing means.
  • The experience is triggered by end user behaviour rather than automated processes, until we discover more about the rest of the story.

I want to [achieve],…

We now want to ensure that we describe the Customer Service Representative’s objective in this part of the user story, so that we can start to understand our scope and design our solution.

As a Customer Service Representative accessing the standard Customer Service Hub application, I want to see all of my priority ‘1 – Blocker’ Cases in a separate list sorted by oldest to newest creation date,…

To add to our previous understanding, we now know:

  • The user has a focus on Cases that need the highest amount of attention, and these should be categorised by priority. Right now we don’t know the full list of priorities, but we can add that as a known unknown in our design.
  • The user needs a new view for just the Cases categorised by this priority, and the out-of-the-box priorities are High, Medium, Low. It seems like we need to carry out Column and List configuration in Dataverse here.
  • The List that we configure needs to include the Created On date, and needs a sorting on this Column too.

So that I can [action].

The primary purpose of this part of the user story is to justify the action through behaviour. Some consider this part of the user story optional, however I like to ensure it’s included in every user story as it can significantly change the estimate required to deliver.

This part of the user story doesn’t just have design benefits, but it can also help us prioritise the user story against other user stories in the backlog when we are working in iterations or sprints.

As a Customer Service Representative accessing the standard Customer Service Hub application, I want to see all of my priority ‘1 – Blocker’ Cases in a separate list sorted by oldest to newest creation date, so that I can ensure that we do our best to meet our 1 day ‘solution or workaround’ Service Level Agreement (SLA) for blocked customers.

We now know why this design is so important, and we can deduce the following:

  • The organisation makes promises within their agreements with customers to ensure that business processes aren’t blocked for more than one day, and this needs to be a core emphasise within the design.
  • We can ask if we can further improve the design by introducing system triggered Service Level Agreement functionality.
  • Most importantly, another business initialism has been cleared up, by clarifying why the customer keeps writing SLA all over their documents!

Isn’t This Too Much Detail?

Not at all. It’s unlikely that we will every get to this level of detail within one round of workshops, however, through refinement during iterations or sprints, this can tell us almost exactly how we need to build a feature. It will also help us more accurately estimate our delivery and provide a higher chance of passing tests after deployment.

One phrase I frequently hear is ‘we don’t need to worry, it’s just out of the box functionality’, but from one sentence regarding standard functionality, we have been able to arrive at 10 conclusions with definitive design that definitely carry an associated effort.

I am sure others reading this will find additional conclusions too, and this is the great thing about user stories – multiple perspectives can help to narrow down exactly what the client is asking for, and ultimately lead to a higher quality delivery.