Tips for Agile Teams
How to Manage Production Support in Agile
Learn HOW to manage application Production Support in Agile and how to take strategic decisions on your product
You moved from the product development phase into a production support in Agile phase. Your product is out on the market. Congratulations! 🥳🥳🥳
You have the first support request, and you create an Epic/Feature on your product backlog to track production support in Agile. But shortly, you realize that because of the issues you are facing on production support, there is not that much time left for the team to develop new functionalities as you’d like🏃😓🏃. There are issues in production that need team attention as soon as possible🚨🚨🚨. And you are on a constant fire fighting🧑🚒🧑🚒🧑🚒.
How are we suppose to manage production support in Agile?
When it comes to production support, you can split it into planned and unplanned production support. You want to manage both types of support your agile teams offer.
When it comes to production support, your agile teams will have to manage bugs, requests for information, enhancements, upgrade in technology, issues with 3rd party vendors.
When a product is in production, the Product Backlog changes its structure from only building new functionalities to the following:
- new functionalities
- spikes
- production support
- technical refactoring
Why do you want to track production support in Agile?
In short, we are tracking the production support effort to be able to answer the following questions:
- How much time and effort your agile teams invest in production support?
- How much does the production support cost us? Are we profitable? Are we charging enough to our clients?
- What kind of support do we offer: bug fixes, enhancements, request for information, configuration issues, updates on technologies?
- What is the most expensive part of our support?
- Is the production support something that a junior person can do?
- Do we need a person dedicated to production support of our product?
- Do we need to allocate production support during our sprints?
- Can we add new functionalities to our product to minimize the product support effort of your agile team?
- How much of the production support we do is unplanned?
- Is the unplanned production support jeopardizing our sprint?
- I the effort we spend on production support constant across multiple sprints and teams, or there a spike in work?
- Are we profitable?
- Are we offering adequate support to our clients?
- Can we predict the production support our clients need?
We must track every production support in Agile to take strategic decisions.
What are we tracking?
Your initial goal is to understand the magnitude of the production support your agile teams do. Then make decisions based on the data.
If your agile team spends one h here and there for production support, it is fine, but if it’s 40h a sprint/2 weeks, we should do something about it.
How do we track?
Step 1: Define your planning quarters
From a business perspective, the quarters link to financial planning. For example, the companies that have the financial year January to December define their quarters as three months timebox starting from January. Other companies begin to set them from the moment they put in place this method.
If you are a software development company, your timeboxes should be 5–6 sprints of 2 weeks. In the Scaled Agile Framework, they are called Program Increments.
Step 2: Track support per quarters
Usually, teams will create one Jira epic for Support or maintenance and dump everything there without knowing the impact of the support on their team and business.
If you are using Jira or Team Foundation Server, you’ll create a Support Epic for each quarter. I recommend you create first only one epic called Product Support. If there is a lot of Product Support your agile team(s) do, you can split it into bug fixing, enhancements, and maintenance. Each quarter will have a new Jira Epic.
Step 3: Add placeholder Production Support Stories to your Product backlog
If you are using Scrum as a software development methodology, each sprint will have a dedicated User Story for Production Support.
Initially, there will be no story points for these User Stories. As you learn more about how much effort it takes for your team(s) to do production support and what kind of issues are there, you can start adding story points to your production user stories and plan them better.
Step 4: Create sub-tasks inside your Product Support stories for actual support work
At the beginning of the sprint, your Product Support Story will be empty. As you learn about the Production Support need for your application, you add sub-tasks.
You should add to the current sprint ONLY the high priority issues and plan for the next sprint the production support application issues that are less urgent.
When someone closes a sub-task should log:
- What caused the issue
- What fix did (s)he applied.
- Log the time it took to resolve the issue. Here the team member must include meeting times, research, clarifications; time spent writing emails, development, testing, deployment, client communication, everything.
- Propose how can the issue be fixed in the future
Step 5: Review the production effort at each Retrospective meeting
At the end of each sprint, or every two weeks, report the Application Product Support in each agile team and use it to learn how you can improve your processes and product together with the team.
Step 6: Take strategic decisions on regards to Product Support
At the end of 3 months of tracking your production support, you should answer almost all the questions from the article's beginning.
Now it’s time to review your software's production support and decide how to optimize your operations and develop your product.
Here are a few ideas of what decisions you can make:
- If your software production support effort is constant, you can plan specific story points/effort each sprint. Some sprints might require more effort, but you can also limit the agreed value's support inside the Agile team.
- Identify the most expensive type of production support and try to standardize it so that even a more junior person can offer the same assistance.
- Identify the most common issues you face on your software production support and automate it or develop new product features that don’t require production support.
- Update your product or service pricing
You might be interested in:
