Managing Unexpected Tasks in Software Development Teams

• In the first scenario, development and support tasks need to be handled simultaneously without clear priorities, complicating task management.
• In the second scenario, customers often submit unexpected, urgent tasks to the development team. The extra workload adds to the risk of failing to achieve the sprint goal.

The development team needs to find a way to handle trivial, unexpected support work and improve work efficiency.

• For the first scenario, divide developers into two groups, one for development and the other for emergencies. The development group focuses on development while the other group stands ready to unexpected work (also responsible for easy, loosely coupled development). Both groups shall comply with rules of the development team to manage work items.
• The second scenario is more common. The following describes how to deal with work priority and requirement changes systematically.

Solutions for the second scenario:

Managing work items is essential for the development team. Therefore, before forming work items, we need to determine who is responsible for work items (that is, the source of work items), and make a plan for work item implementation.

1. Specify the product manager as the unique requirement source.
2. Sort out the product backlog and prioritize work items.
3. Revise the plan based on the capabilities of the development team and update the sprint goal.
4. Review and find where enhancements are needed.
5. Analyze sprints for continuous improvement and cultivate talent to build a cross-functional team.

The following diagram displays the solution.

Figure 1 Solution diagram

1. Specify the requirement owner.

   Specify the requirement owner as the unique requirement source. In CodeArts, the project manager is the requirement owner. The requirement owner needs to:

   • Have a good understanding of the requirements of stakeholders, customers, and users in the project (including the unexpected work items mentioned above) and their priorities. From this perspective, the product manager acts as the requirement owner.
   • Communicate with the development team about the features to be developed and the development sequence. The requirement owner also must ensure that there are clear feature acceptance criteria. From this perspective, service analysts and testers act as the requirement owner.

   Moreover, the requirement owner must be able to make economical decisions for more benefits at the version, sprint, and backlog levels. In the following, the product manager (like product owner in Scrum) is used for requirement owner.

   The following figure shows the main responsibilities of a product manager.

   Figure 2 Main responsibilities of the product manager
   

   The highlighted responsibilities in Figure 2 are related to the unexpected work in a sprint. The product manager needs to clearly communicate with stakeholders to determine the priority of each unexpected task and whether it must be completed in this sprint based on business value and management benefits. Once it is determined that these unexpected tasks are of high priority and must be completed in this sprint, the backlog needs to be sorted out.

2. Sort out the backlog.

   Sorting out the backlog means placing high-priority tasks in the sprint backlog. For details about the sprint backlog, see More Details About Sprint Backlogs.

   • Backlog is a prioritized list of expected product functions.
   • Work items are the to-dos in a backlog. For users and customers, most work items are valuable features and functions. Work items also include defect rectification, technical improvement, and knowledge acquisition, and any work that the product owner considers valuable (even unexpected valuable work).
   • Sorting refers to three important activities: establishing and refining, evaluating, and prioritizing work items.

     Change the backlog structure by sorting out activities.

     Figure 3 Backlog structure
     

     Figure 4 shows the sorting result in CodeArts.

     Figure 4 Requirement sorting
     

   The red boxes in Figure 4 show the sorting by the product manager. The unexpected training task is properly prioritized and the workload is evaluated. In addition, the task of querying product names is broken down. As the final decision-maker of sorting, the product manager is responsible for sorting out unexpected work. A good product manager can coordinate stakeholders to arrange enough time for sorting based on the characteristics of the development team and project type. In addition, the development team needs to estimate the workload of unexpected work and help the product manager prioritize work items based on technology dependencies and resource constraints. If an unexpected training task has a high priority, it will be added to the backlog of the current sprint.

3. Revise the plan.

   Revise the plan based on the capabilities of the development team and update the sprint goal. Before revising the plan, we need to know what is a plan in Agile development and what are the differences between plans in Agile and traditional development modes.

   As the Agile Manifesto advocates responding to changes instead of always following the plan, the Agile development focuses on responding to changes while the task-driven development tends to follow the plan.

   Sequential development is plan-driven. The plan is the authoritative information source of how and when work is done. Therefore, the plan is always followed. In contrast, Agile prefers revising plans based on real-time information, rather than sticking to a potentially incorrect plan.

   Agile development is not about following a predetermined plan or prediction, but revising the plan based on the valuable economic information that emerges in the process. Therefore, you can adjust the plan after sorting out work items. Work items in the original plan may be moved to the next sprint. The capacity of a fixed development team remains unchanged in a sprint. Adding unexpected work items without removing others will definitely bring pressure to the team and disrupt the delivery pace. Therefore, the equivalent exchange principle shall be followed, which means that the replaced work has the same workload as the unexpected high-priority work.

   Figure 5 Equivalent exchange principle
   

   Figure 6 and Figure 7 show the exchange details in CodeArts.

   Figure 6 Equivalent exchange 1
   
   Figure 7 Equivalent exchange 2
   

   Finally, move the low-priority work item with a similar workload back to the backlog. The equivalent exchange of work items is completed in CodeArts.

4. Review the sprint for improvement.

   Conduct a sprint retrospective to improve the process based on the needs of the development team, thereby boosting morale for higher output efficiency. Analyze the unexpected work in sprints for continuous improvement. In Agile development, prioritizing changes over following the plan is important, but the development team needs to go out for the sprint when there are no interference (unexpected work). Therefore, we should think about why there would be interference in each sprint and find a solution.

   Figure 8 and Figure 9 are a good practice of CodeArts, which can provide objective data for review. Unexpected work items added to the sprint backlog can be managed in Modules of CodeArts. That is, create a module for unexpected tasks before creating a user story, and then select this module in the user story. This is to measure and analyze such unexpected work in subsequent sprints (which can be sorted by module to facilitate measurement and analysis) for continuous improvement.

   Figure 8 Creating a module for unexpected work
   
   Figure 9 Creating a user story
   

   Choose Statistics > Create Report > Custom Report. On the page that is displayed, set Analysis Dimension (X-axis/Table row values) to Sprint and Measure (Y-axis/Table cell values) to Actual person-hour. Select Module on the page displayed after clicking Add Filtering Criterion. Click Save to analyze the statistics in diagrams and tables.

   Figure 10 Diagram display
   
   Figure 11 Table display
   
5. Cultivate talent.

   At the same time, cultivate talent to build a cross-functional team. We not only seek to handle emergencies, but achieve higher efficiency.

   It is obvious that we should find the right person for each task (including unexpected tasks). If the person is unavailable, find another to complete the task in time. Each team member is responsible for making wise decisions when faced with uncertainties. A development team composed of T-shaped talent can always find someone to tackle tasks, achieving a higher efficiency.