With any application there are parts that are more critical if they break Other areas are less critical, but nice to have. How do you figure out which are part of your Critical Path?
A Critical Path is considered: Anything that inhibits a necessary core functionality.
It’s easy assume to assume we already know what is Critical or not in our applications. It’s good to have a strategy to evaluate the criticality of one feature to another.
Understanding what features are Critical Path helps understand things like: urgency of fixes, amount of unit/automation testing should be written, and amount of time to invest in making it resilient to failure.
Create a list of features
List out features of your application, both small and large. This list should be extensive. Collaborating with team members is a great way to remember every little features that exist.
Next we need a way to score and compare features.
Create a Critical Path Rubric
Create a list of questions to evaluate features against each other. Here are 7 great questions to ask of each feature to test if it’s a Critical Path feature:
(Click to expand each)
1) Does it have a high volume of usage?
Example: On this blog articles are ready many times a day, search only used a couple times a week.
Does the system, workflow, or feature see more than X volume of usage per day?
One of the simpler tests at first blush, how much is it used. However, personal anecdotes, preference, and bias can cloud our judgment of what the most used items are.
If we aren’t measuring usage, then we can only guess with an anecdote how much something might be used. Thus it’s important to truly add monitoring to systems.
When we can measure the volume of usage the feature or workflow by users. Each time a someone uses a feature or system we can consider it a vote towards that item.
2) If it broke would it disrupt / make common workflows unusable?
Example: Does it prevent the user from getting to other Critical Paths, like replying?
Often there are single spots of failure in a workflow. For instance maybe there is only one ‘next’ button on a view. Without it there is no other way to progress to the next step. The only option they may be to give up on what they want to accomplish until its fixed.
3) If it broke would there be a comparable workaround?
Example: Instead of logging into a site with Facebook Login, logging in with username & password.
This one is a counter point to the previous, even a workflow is common, there is a second way to accomplish the workflow. It might not be perfect or ideal, but the support team can direct users to the alternate path while the main workflow is repaired.
For example there might be multiple places on a site a user could go to try to remove a photo they posted. If one page doesn’t seem to be working, a user could go to another view that also shows your photo and try there.
4) If it broke would support receive a moderate to large volume of calls?
Example: Severity 3 or higher
This also builds upon the previous, if the support team does receive calls about the broken workflow, what would the anticipated call value be? If the volume would be large and overwhelm them, the feature is likely part of a Critical Path.
5) If it broke would we consider an app-wide rollback instead of a bug fix first.
Example: All images are failing to load.
App-wide rollbacks are fast, they quickly switch code back to how it was a couple hours or days ago. This is a great option to leverage when something critical breaks, but it’s not a lightly taken path as it will also roll back any other fixes or features that also would like to be out.
If rollbacks are on the table as an option if a specific workflow were to break, it most certainly is considered a critical item.
6) Would a customer consider leaving if it was broken for more than a week?
Example: Unable to reply to emails.
Customers and users depend on your application, they form a dependence on it work and working well. If something they consider critical within your app breaks, the trust in the reliability is eroded.
Some items might be so critical to a customer that they may even consider canceling if it was broken for a significant length of time.
They won’t probably cancel because they can’t change their profile photo, but other functionality they most certainly may.
7) Would the CEO be asking questions if it was broken?
Example: Inbox failing to load / empty, red bars, and mayhem.
The CEO carries weight and has their values. If something major breaks the CEO will know and be aware. If a workflow is so critical that they would be made aware of it breaking, you can guarantee it’s likely critical to the organization.
Score and Rank Features
Looking at each feature score each feature’s Criticality using the questions you’ve developed.
For example you could use a 1-5 points scoring.
- Not Critical
- Hardly Critical
- Somewhat Critical (Neutral)
- Critical
- Very Critical
Once scored, what do we do with this new understanding?
Conclusion
With these tools at hand, there is now a way to understanding what features are Critical Path.
There is a method to understanding the urgency of bug fixes. You know the areas of the application that more unit/automation testing focus should be put. And can start to think about investing in making these features more resilient to failure.
Building with intentionality around Critical Paths can take your application to the next level of reliability.
(cover photo credit: Jonathan Stassen / JStassen Photography)