WO2025013147A1 - バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム - Google Patents

バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム Download PDF

Info

Publication number
WO2025013147A1
WO2025013147A1 PCT/JP2023/025373 JP2023025373W WO2025013147A1 WO 2025013147 A1 WO2025013147 A1 WO 2025013147A1 JP 2023025373 W JP2023025373 W JP 2023025373W WO 2025013147 A1 WO2025013147 A1 WO 2025013147A1
Authority
WO
WIPO (PCT)
Prior art keywords
backlog
completed
sprint
story
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/JP2023/025373
Other languages
English (en)
French (fr)
Inventor
健太 篠原
紀貴 堀米
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
NTT Inc
Original Assignee
Nippon Telegraph and Telephone Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Nippon Telegraph and Telephone Corp filed Critical Nippon Telegraph and Telephone Corp
Priority to PCT/JP2023/025373 priority Critical patent/WO2025013147A1/ja
Priority to JP2025532242A priority patent/JPWO2025013147A1/ja
Publication of WO2025013147A1 publication Critical patent/WO2025013147A1/ja
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063—Operations research, analysis or management
    • G06Q10/0631—Resource planning, allocation, distributing or scheduling for enterprises or organisations

Definitions

  • the present invention relates to a backlog management device, a backlog management method, and a backlog management program for managing a backlog in Scrum development, a software development methodology.
  • Scrum development is known as an agile development methodology. Scrum is a framework in which a development team repeats short development cycles. In Scrum development, the backlog (an ordered list of items required for product creation, such as functions, requirements, and corrections) is used as the unit of development, and development is carried out repeatedly in short cycles called sprints (see non-patent document 1).
  • backlog an ordered list of items required for product creation, such as functions, requirements, and corrections
  • Non-Patent Document 2 a system for managing the backlog is used (see, for example, Non-Patent Document 2).
  • the system has a function for visualizing the progress of the backlog story points (the amount of work required to complete the backlog) in order to manage the progress of Scrum (see, for example, Non-Patent Document 3).
  • the present invention was made in consideration of these points, and its objective is to accurately grasp the progress of story points even in development processes where the backlog is not completed in one sprint.
  • the backlog management device is a backlog management device that manages a backlog in scrum development, the backlog management device having a memory unit that stores a plurality of backlogs, which are necessary items for creating a product through the scrum development, and each backlog contains information including story points indicating the amount of work required to complete the backlog and a completion percentage indicating the stage according to the progress of the work in the backlog as a percentage of the total work, and is characterized in having a story point aggregation unit that sums up the story points of each backlog to calculate a total story point, and a completion percentage story point calculation unit that multiplies the story points of each backlog by the completion percentage, aggregates the result for each backlog, and calculates the total progress story point.
  • FIG. 11 is a diagram illustrating an example of a data configuration of a backlog registered in a backlog management device according to a comparative example
  • FIG. 1 is a block diagram showing a configuration of a backlog management device according to a comparative example.
  • 10 is a flowchart showing a flow of a backlog management process by a backlog management device according to a comparative example.
  • 1 is a block diagram showing a configuration of a backlog management device according to an embodiment of the present invention.
  • 4 is a diagram illustrating an example of a data configuration of a backlog registered in the backlog management device according to the embodiment;
  • FIG. 10 is a flowchart showing a flow of a backlog management process performed by the backlog management device according to the present embodiment.
  • FIG. 2 is a hardware configuration diagram illustrating an example of a computer that realizes the functions of the backlog management device according to the present embodiment.
  • FIGS. 1 to 3 are diagrams for explaining a backlog management device 5 according to a comparative example of this embodiment.
  • Fig. 1 is a diagram showing an example of the data structure of a backlog 500 registered in the backlog management device 5.
  • Fig. 2 is a block diagram showing the configuration of the backlog management device 5 according to the comparative example.
  • Fig. 3 is a flowchart showing the flow of a backlog management process by the backlog management device 5.
  • a "backlog” is created, which is a list of features, requirements, requests, corrections, and other items needed for the product, and development is carried out in repeated cycles called "sprints," which are units of development time (for example, one or two weeks). For example, when developing software, multiple backlogs are created that are usually completed in one or two sprints to complete the final product (software). This backlog may be rearranged based on priority, and additional items may be added during development.
  • FIG. 1 is a diagram showing an example of the data structure of a backlog 500 registered in a backlog management device 5 (FIG. 2) according to a comparative example.
  • the backlog 500 is created by development members or a person in charge of developing the product (software) to be created, called a product owner, and is registered in the backlog management device 5 .
  • backlog 500 stores information about user stories 510, definition of done 520, acceptance criteria 530, task list 540, story points 550, and status 560.
  • Backlog 500 in FIG. 1 shows, as an example, backlog "1" (backlog 500#1) with priority "1".
  • the user story 510 stores text that explains the functions or services to be developed from the user's point of view.
  • the user story 510 explains what features or services the user is looking for and why.
  • completion 520 stores a completion checklist for the backlog 500 to confirm that the functional requirements and quality are met.
  • This completion checklist defines what and to what extent something needs to be done to be considered "complete.”
  • the acceptance criteria 530 define the conditions under which the functionality defined in the user story 510 is provided. For example, for a software development backlog 500 related to monetary payments, conditions may be defined such as "payment can be made by credit or invoice,””the form cannot be submitted unless all required fields are filled in,” and "after the form is submitted, a confirmation email will be sent to the user and administrator.”
  • the task list 540 lists the specific tasks (work content) for realizing the user story 510.
  • the story points 550 indicate the amount of work (relative estimated amount of work) to be done by the development team for the backlog 500.
  • the amount of work indicated by the story points 550 is not an absolute value, but a relative value determined in relation to the total amount of work within the scrum development period and the amount of work in other backlogs 500. Therefore, the story points 550 may change from the value set at the start of work. Using the story points 550, it is possible to predict the time until the work is completed and to evaluate the content of the work of the development team.
  • the story points 550 are set by the development team or the person responsible for product (software) development, and are registered in the backlog 500.
  • the story points 550 may be updated from the pre-registered value to another value, taking into consideration the progress of other backlogs 500 during the scrum development period.
  • the status 560 stores the progress status of the backlog 500, and includes information on the completion status 561 and the completion sprint number 562.
  • the completed sprint number 562 stores the sprint number at the time of completion. For example, if this backlog 500#1 is completed in the second sprint, sprint "2" is stored as the completed sprint number.
  • the backlog management device 5 is a device that manages the progress of the backlog, and includes a backlog management unit 50, a progress management unit 51, and a progress information recording unit 52.
  • the backlog management unit 50 stores a plurality of backlogs 500 shown in FIG. 2, the status 560 (completion state 561) and story points 550 of each backlog 500 are extracted and described.
  • backlog “1” indicates that the completion state 561 is “completed” and the story points 550 of backlog “1” are “10.”
  • Backlog “2” indicates that the completion state 561 is “completed” and the story points 550 of backlog “2" are "5.” The same applies to backlogs "3" to "5.”
  • the progress management unit 51 has functions for managing the progress of each backlog 500 registered in the backlog management unit 50, including a story point tally unit 511, a backlog completion status determination unit 512, a completed story point tally unit 513, a completed sprint determination unit 514, and a velocity tally unit 515.
  • the story point tallying unit 511 adds up the story points 550 of each backlog 500 registered in the backlog management unit 50 to calculate the total story points.
  • the story point tallying unit 511 records the calculated total story points in the progress information recording unit 52 as story point progress information 200A.
  • the backlog completion state determination unit 512 refers to the completion state 561 of the status 560 for each backlog 500, and determines whether the completion state 561 of the backlog 500 is "completed” or not.
  • the completion status 561 of the backlog 500 is set (registered) from “incomplete” to “completed” when the development team confirms that the tasks shown in the task list 540 of the backlog 500 have been completed in accordance with the completion definition 520.
  • the completed story point tallying unit 513 tallies up the story points 550 of the backlogs 500 whose completion states 561 in the statuses 560 are registered as "completed" among the backlogs 500, and calculates the total completed story points.
  • the completed story point tallying unit 513 records the calculated total completed story points in the progress information recording unit 52 as story point progress information 200A.
  • the completed sprint determination unit 514 refers to the completed sprint number 562 in the status 560 for each backlog 500 whose completion state 561 is "completed," and determines in which sprint the backlog 500 was completed.
  • the velocity tallying unit 515 calculates the velocity for each sprint by summing up the story points 550 of the backlog 500 completed in that sprint. Note that the velocity means the total value of the story points 550 of the backlog 500 completed in that sprint.
  • the velocity tallying unit 515 records the velocity calculated for each sprint in the velocity information 300A of the progress information recording unit 52. In FIG. 2, velocity information 300A indicates that the velocity is "10" for sprint “1", the velocity is "5" for sprint "2”, and the velocity is "15" for sprint "3".
  • the calculation process for managing the progress of each backlog 500 executed by the backlog management device 5 is executed, for example, at the time when each sprint ends. At the end of each sprint, the status 560 (completed state 561 and completed sprint number 562) of each backlog 500 registered in the backlog management unit 50 is updated by the development members or the like.
  • the progress management unit 51 of the backlog management device 5 repeats the processes from steps S10 to S15 for all backlogs 500 registered in the backlog management unit 50 (step S10: calculation for each backlog).
  • the story point tallying unit 511 of the backlog management device 5 acquires information on the story points 550 in the backlog 500, and adds them to the total story points as the story point progress information 200A (step S11).
  • the story point tallying unit 511 repeats this process for all backlogs 500, thereby adding up the story points 550 of each backlog 500 and calculating the total story points.
  • the backlog completion state determination unit 512 refers to the completion state 561 of the status 560 for the backlog 500, and determines whether the completion state 561 of the backlog 500 is "completed” (step S12). If the completion status 561 of the backlog 500 is not "completed” (step S12 ⁇ No), the process proceeds to step S15. On the other hand, if the completion status 561 of the backlog is "completed” (step S12 ⁇ Yes), the process proceeds to the next step S13.
  • step S13 the completion story point tallying unit 513 acquires information on the story points 550 of the backlog 500 whose completion state 561 is registered as “completed”, and adds it to the total completion story points as the story point progress information 200A.
  • the completed story point tallying unit 513 performs this process for all backlogs 500 whose completion states 561 are registered as "completed,” and adds up the story points 550 to calculate the total completed story points.
  • the completed sprint determination unit 514 refers to the completed sprint number 562 in the status 560 for each backlog 500 whose completion state 561 is "completed” among the backlogs 500, and determines in which sprint the backlog 500 was completed. Then, the velocity aggregation unit 515 adds the story points 550 of the backlog 500 completed in that sprint to the velocity of the corresponding sprint in the velocity information 300A (step S14). The velocity aggregation unit 515 performs this process for all backlogs 500 whose completion status 561 is registered as “completed”, totals the story points 550 for each sprint, and calculates the velocity of each sprint, which is indicated by the velocity information 300A.
  • the progress management unit 51 repeats the process of steps S11 to S14 for all backlogs 500 (step S15: end of calculation for each backlog), and ends the process.
  • the backlog management device 5 of the comparative example by referring to the story point progress information 200A, it is possible to check the progress by referring to the "total completed story points"("30" in FIG. 2 ), which is the sum of the story points 550 of the completed backlog 500 against the "total story points" of the entire backlog 500 ("100" in FIG. 2 ).
  • the velocity information 300A it is possible to check the velocity value for each sprint. This makes it possible to predict the time until the completion of the work and evaluate the content of the work of the development team. The time until the completion of the work is predicted by calculating the predicted number of sprints using the total story points of the planned sprints and the velocity of the past sprints.
  • velocity is used to visualize the state of the team.
  • the story points 550 of the backlog 500 are added to the "total story points for completion", and the story points 550 are also added to the velocity of each sprint in the velocity information 300A.
  • the progress status does not change even if the work (task) has progressed halfway. Therefore, it is not possible to accurately grasp the progress of development.
  • the backlog management device 1 adds the completion percentage to the status of the backlog 100 (FIG. 5, described later) and multiplies the story points of the backlog 100 by the value of the completion percentage to calculate the total value of the story points.
  • the backlog management device 1 also calculates the velocity taking into account the progress of the completion percentage for each sprint. This allows the backlog management device 1 to accurately grasp the progress status of the backlog even if the backlog is not completed in one sprint. This will be explained in detail below.
  • FIG. 4 is a block diagram showing the configuration of the backlog management device 1 according to the present embodiment.
  • the backlog management device 1 is realized by a computer including a control unit, an input/output unit, and a storage unit (not shown) (see FIG. 7 for details).
  • the input/output unit receives registration of the backlog 100 from an external device, and receives information regarding various setting changes.
  • This input/output section is composed of a communication interface for transmitting and receiving information via a communication line, and an input/output interface for inputting and outputting information between an input device such as a keyboard and an output device such as a monitor (not shown).
  • the storage unit is composed of a hard disk, a flash memory, a RAM (Random Access Memory), or the like.
  • This storage unit temporarily stores a program (backlog management program) for executing each function of the control unit, and information necessary for the processing of the control unit.
  • This storage unit also stores a backlog management unit 10 that stores a backlog 100 (FIG. 5) described below, and a progress information recording unit 13 that stores information related to the progress of story points (story point progress information 200) and velocity information (velocity information 300).
  • FIG. 5 is a diagram showing an example of the data configuration of the backlog 100 registered in the backlog management device 1 (FIG. 4) according to this embodiment.
  • the backlog 100 in this embodiment stores information on a user story 110, a definition of completion 120, an acceptance criterion 130, a list of tasks 140, story points 150, and a status 160.
  • the information on the user story 110, the definition of completion 120, the acceptance criterion 130, the list of tasks 140, and the story points 150 is similar to the information on the user story 510, the definition of completion 520, the acceptance criterion 530, the list of tasks 540, and the story points 550 in the backlog 500 of the comparative example shown in FIG 1, and therefore a description thereof will be omitted.
  • the completion percentage 161 and sprint history information 162 are stored in the status 160.
  • the completion rate 161 is information that indicates a stage according to the progress of the work (task) of the backlog 100 as a percentage of the entire work.
  • the completion rate 161 is shown as a numerical value (rate) divided into a number of stages from “0: not started” to "1.0: completed” according to the work content, as shown in FIG.
  • the completion rate is judged based on seven levels: “0: not started”, “0.1: BD completed", “0.3: FD completed”, “0.4: Analysis completed”, “0.7: M/UT completed”, "0.9: IT completed”, and "1.0: Complete”.
  • the completion rate 161 may be stored as a stage value (ratio) according to the progress of work at the end of each sprint by the development members or development manager of the backlog 100. Also, the completion rate determination unit 122 described later may receive registration of how much of the tasks (work contents) shown in the task list 140 have been completed, and register a stage value (ratio) according to the result.
  • the stages of the completion rate 161 are not limited to the seven stages described above, but may be set appropriately depending on the work content of the product (software) development.
  • the sprint history information 162 stores, for each sprint in the backlog 100, the completion percentage at the start of the sprint and the completion percentage at the end of the sprint. 5, as the sprint history information 162 of backlog "1" (backlog 100#1), "0-0.3” is stored, indicating that the completion ratio at the start of sprint “1” (the first sprint) is “0: not started” and the completion ratio at the end is “0.3: FD completed.” Also, “0.3-1.0” is stored, indicating that the completion ratio at the start of sprint "2" (the second sprint) is "0.3: FD completed” and the completion ratio at the end is “1.0: completed.”
  • the control unit (not shown) is responsible for all the processes executed by the backlog management device 1, and includes a backlog registration unit 11 and a progress management unit 12.
  • the backlog registration unit 11 accepts registration of the backlog 100 from outside and stores it in the backlog management unit 10.
  • the backlog registration unit 11 can also accept registration of a new backlog 100 during development.
  • the backlog registration unit 11 accepts the information and updates the information of that backlog 100.
  • the completion percentage 161 stored in the status 160 of each backlog 100 is changed, the backlog registration unit 11 accepts the change information and updates the completion percentage 161 of that backlog 100 .
  • the progress management unit 12 calculates the story points (total progress story points) that are the total progress, and the velocity, taking into account the completion rate of each backlog 100.
  • This progress management unit 12 includes a story point tallying unit 121, a completion rate determination unit 122, a completion rate story point calculation unit 123, and a velocity tallying unit 124.
  • the story point tallying unit 121 totals the story points 150 of each backlog 100 registered in the backlog management unit 10 to calculate the "total story points.”
  • the story point tallying unit 121 records the calculated total story points in the progress information recording unit 13 as story point progress information 200.
  • the completion rate determination unit 122 refers to the completion rate 161 of the status 160 of the backlog 100 and determines the completion rate of the backlog 100 .
  • the completion percentage determination unit 122 may accept registration of the extent to which a task (work content) listed in the task list 140 has been completed, determine the extent to which work has been completed based on the result, and register the determined extent as the completion percentage 161 of the status 160.
  • the completion percentage determination unit 122 stores in the status 160 of the backlog 100 the completion percentage at the start of the sprint and the completion percentage at the end of the sprint as sprint history information 162.
  • the completion percentage story point calculation unit 123 multiplies the story points 150 registered in the backlog 100 by the completion percentage 161 for each backlog 100, and calculates the “total progress story points” by aggregating the results for all backlogs 100.
  • the completion rate story point calculation unit 123 records the calculated total progress story points in the progress information recording unit 13 as story point progress information 200.
  • the velocity tallying unit 124 records the velocity calculated for each sprint in the velocity information 300 of the progress information recording unit 13 .
  • velocity information 300 indicates that the velocity is 18.0 for sprint “1", 17.5 for sprint "2", and 14.5 for sprint "3".
  • the backlog management device 1 executes a calculation process for managing the progress of each backlog 100, for example, when each sprint ends.
  • the calculation process may be executed when a new backlog 100 is registered in the backlog management unit 10 or when the value of any of the story points 150 of each backlog 100 is changed. It is assumed here that the backlog registration unit 11 accepts registration of the backlog 100 from outside, and that backlogs "1" to "5" are stored in the backlog management unit 10 as shown in FIG.
  • the progress management unit 12 of the backlog management device 1 repeats the processes from steps S1 to S6 for all backlogs 100 registered in the backlog management unit 10 (step S1: calculation for each backlog).
  • the story point tallying unit 121 of the backlog management device 1 acquires information on the story points 150 (FIG. 5) of the backlog 100, and adds them to the total story points as the story point progress information 200 (step S2).
  • the story point tallying unit 121 repeats this process for all backlogs 100, thereby adding up the story points 150 of each backlog 100 and calculating the total story points.
  • the completion percentage determination unit 122 refers to the completion percentage 151 of the status 160 of the backlog 100, and determines the completion percentage of the backlog 100 (step S3). In addition, each time a sprint ends, the completion percentage determination unit 122 stores in the status 160 of the backlog 100 the completion percentage at the start of the sprint and the completion percentage at the end of the sprint as sprint history information 162.
  • the completion percentage story point calculation unit 123 multiplies the story points 150 registered in the backlog 100 by the completion percentage 161 of the backlog 100, and adds the result to the total progress story points as the story point progress information 200 (step S4).
  • the completion percentage story point calculation unit 123 repeats this process for all backlogs 100, thereby taking into account the completion percentages 161 of each backlog 100, summing up the story points 150, and calculating the total progress story points.
  • the completion rate story point calculation unit 123 records the calculated total progress story points in the progress information recording unit 13 as story point progress information 200.
  • the velocity aggregation unit 124 refers to the sprint history information 162 of the status 160 for each backlog 100, and calculates the execution ratio for each sprint (the ratio of work executed in that sprint to the total work in that backlog 100). Then, for each sprint in the backlog 100, the velocity aggregation unit 124 multiplies the story points 150 registered in that backlog 100 by the execution rate, and adds the result to the velocity of the corresponding sprint in the velocity information 300 (step S5). The velocity tallying unit 124 performs this process for the entire backlog 100 , totals the story points for each sprint, and calculates the velocity of each sprint, which is indicated by velocity information 300 .
  • the progress management unit 12 repeats the processing of steps S2 to S5 for all backlogs 100 (step S6: end of calculation for each backlog), and ends the processing.
  • the backlog management device 1 of this embodiment by referring to the story point progress information 200, it is possible to check the "progress total story points"("50" in FIG. 4) against the “total story points"("100” in FIG. 4) of the entire backlog 100, thereby making it possible to more accurately check the current progress status. Furthermore, by referring to the velocity information 300, it is possible to check a more accurate velocity value for each sprint. This makes it possible to more accurately predict the time until the work is completed and to more accurately evaluate the work content of the development team.
  • the backlog management device 1 is realized by a computer 900 having a configuration as shown in FIG. 7 is a hardware configuration diagram showing an example of a computer 900 that realizes the functions of the backlog management device 1 according to this embodiment.
  • the computer 900 includes a CPU 901, a ROM (Read Only Memory) 902, a RAM 903, a HDD (Hard Disk Drive) 904, an input/output I/F (Interface) 905, a communication I/F 906, and a media I/F 907.
  • the CPU 901 operates based on a program (backlog management program) stored in the ROM 902 or HDD 904, and performs control by the control unit (backlog registration unit 11, progress management unit 12) ( Figure 4).
  • the ROM 902 stores a boot program executed by the CPU 901 when the computer 900 is started, programs related to the hardware of the computer 900, etc.
  • the CPU 901 controls an input device 910 such as a mouse or keyboard, and an output device 911 such as a display or printer, via an input/output I/F 905.
  • the CPU 901 acquires data from the input device 910 via the input/output I/F 905, and outputs generated data to the output device 911.
  • a GPU Graphics Processing Unit
  • a processor may be used as a processor together with the CPU 901.
  • the HDD 904 stores the programs executed by the CPU 901 and the data used by the programs.
  • the communication I/F 906 receives data from other devices via a communication network (e.g., NW (Network) 920) and outputs the data to the CPU 901, and also transmits data generated by the CPU 901 to other devices via the communication network.
  • NW Network
  • the media I/F 907 reads a program (backlog management program) or data stored in the recording medium 912, and outputs it to the CPU 901 via the RAM 903.
  • the CPU 901 loads a program related to the target processing from the recording medium 912 onto the RAM 903 via the media I/F 907, and executes the loaded program.
  • the recording medium 912 is an optical recording medium such as a DVD (Digital Versatile Disc) or a PD (Phase change rewritable Disk), a magneto-optical recording medium such as an MO (Magneto Optical disk), a magnetic recording medium, a semiconductor memory, etc.
  • CPU 901 of computer 900 executes a program loaded onto RAM 903 to realize the functions of a backlog management program.
  • Data in RAM 903 is also stored in HDD 904.
  • CPU 901 reads and executes a program related to a target process from recording medium 912. Additionally, CPU 901 may read a program related to a target process from another device via a communication network (NW 920).
  • NW 920 a communication network
  • the backlog management device of the present invention is a backlog management device 1 that manages a backlog 100 in scrum development, the backlog management device 1 having a memory unit that stores a plurality of backlogs 100, which are necessary items for creating a product through scrum development, and each backlog 100 has information recorded therein including story points 150 that indicate the amount of work required to complete the backlog 100 and a completion percentage 161 that indicates the stage according to the progress of the work in the backlog 100 as a percentage of the entire work, and is characterized in having a story point counting unit 121 that adds up the story points 150 of each backlog 100 to calculate total story points, and a completion percentage story point calculation unit 123 that multiplies, for each backlog 100, the story points 150 of the backlog 100 by the completion percentage 161, counts the result for each backlog 100, and calculates the total progress story points.
  • the backlog management device 1 can calculate the total progress story points using the completion rate. Therefore, the backlog management device 1 can accurately grasp the progress status of story points even in the case of a development process in which the backlog is not completed in one sprint.
  • the software development process for example, in the case of Scrum development where documents such as basic design documents and functional design documents are created, even if the work is not completed in one sprint, the progress of story points can be accurately grasped. Since a backlog is not created for each process but is basically created for a series of work until a certain function is completed, by calculating the progress using the completion rate of the backlog, it is possible to grasp the situation more accurately than with conventional techniques.
  • the backlog management device 1 is characterized in that it further includes a velocity aggregation unit 124, in which the completion percentage at the start and end of a sprint, which is a unit of repeated development time, is stored for each sprint as sprint history information 162 in each backlog 100, and which refers to the sprint history information 162, calculates an execution percentage for each sprint, which is the percentage of work performed within the sprint to the total work in the backlog 100, multiplies the story points of the backlog 100 by the execution percentage, and calculates the value obtained by adding up the results for each sprint for each backlog 100 as the velocity for each sprint.
  • a velocity aggregation unit 124 in which the completion percentage at the start and end of a sprint, which is a unit of repeated development time, is stored for each sprint as sprint history information 162 in each backlog 100, and which refers to the sprint history information 162, calculates an execution percentage for each sprint, which is the percentage of work performed within the sprint to the total work in the backlog 100, multiplies the story points of the backlog 100
  • the backlog management device 1 can refer to the sprint history information to calculate the execution rate, which is the proportion of work performed within a sprint, for each sprint, and calculate the velocity for each sprint. Therefore, even in the case of a development process in which the backlog is not completed in one sprint, the backlog management device 1 can accurately grasp the velocity for each sprint according to the progress of the work.
  • the completion rate is 0 for a stage where work has not yet been started, 0.1 for a stage where basic design has been completed, 0.3 for a stage where functional design has been completed, 0.4 for a stage where analysis has been completed indicating that program definition has been completed, 0.7 for a stage where M/UT (Make/Unit Test) has been completed indicating that coding and unit testing has been completed, 0.9 for a stage where IT (Integration Test) has been completed indicating that integration testing has been completed, and 1.0 for a stage where all work has been completed.
  • the completion rate can be set according to the amount of work involved in the actual development process. This allows the backlog management device 1 to grasp the progress status more accurately.

Landscapes

  • Business, Economics & Management (AREA)
  • Human Resources & Organizations (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Economics (AREA)
  • Operations Research (AREA)
  • Game Theory and Decision Science (AREA)
  • Development Economics (AREA)
  • Marketing (AREA)
  • Educational Administration (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

バックログ管理装置（１）は、複数のバックログ（１００）を記憶するバックログ管理部（１０）を有し、各バックログ（１００）には、当該バックログ（１００）の作業量を示すストーリーポイントと、完成割合とが記載されており、各バックログ（１００）のストーリーポイントの合計である合計ストーリーポイントを算出するストーリーポイント集計部（１２１）と、各バックログ（１００）のストーリーポイントと完成割合とを乗算し、その結果を各バックログ（１００）について集計した進捗合計ストーリーポイントを算出する完成割合ストーリーポイント計算部（１２３）と、を備える。

Description

バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム
　本発明は、ソフトウェアの開発手法であるスクラム開発において、バックログを管理する、バックログ管理装置、バックログ管理方法、および、バックログ管理プログラムに関する。
　アジャイル開発の手法として、スクラム開発が知られている。スクラムは、開発を行うチームにおいて、短期間の開発サイクルを繰り返し行うフレームワークである。
　スクラム開発では、バックログ（プロダクト作成にあたり、機能や要求、修正などの必要項目を順番に並べたリスト）を開発の単位とし、スプリントと呼ばれる短いサイクルで繰り返し開発を行っていく（非特許文献１参照）。
　一般的に、スクラム開発ではバックログを管理するシステムが利用される（例えば、非特許文献２参照）。当該システムには、スクラムの進捗状況を管理するためのバックログのストーリーポイント（バックログを完成するための作業量）の消化状況を可視化する機能が備わっている（例えば、非特許文献３参照）。
Ken Schwaber, Jeff Sutherland,「スクラムガイド」，2020年11月，［online］,［令和5年6月30日検索］,インターネット＜URL：https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf＞ Claire Maynard,「Jira Softwareを使用したスクラムの学習」，ATLASSIAN，［online］,［令和5年6月30日検索］,インターネット＜URL：https://www.atlassian.com/ja/agile/tutorials/how-to-do-scrum-with-jira-software＞ 「リリース バーンダウン」，［online］,［令和5年6月30日検索］,インターネット＜URL：https://ja.confluence.atlassian.com/jirasoftwarecloud/release-burndown-777002702.html＞
　スクラム開発では、バックログを細かい価値（作業内容）に分割することにより、そのバックログを作る単位を小さくし、短期間のスプリントで実現することが原則となる。しかしながら、ＢＤ（Basic Design：基本設計）書やＦＤ（Function Design：機能設計）書等のドキュメントを作成した上で実装するような開発プロセスの場合、１つのスプリントでバックログが完成しないことがある。そのため、従来の管理システムでは、バックログが完成しないことによりストーリーポイントの進捗状況が変化せず、開発の進捗状況を正しく把握することができないという問題があった。
　このような点を鑑みて本発明がなされたのであり、本発明は、１つのスプリントでバックログが完成しない開発プロセスの場合においても、ストーリーポイントの進捗状況を正確に把握することを課題とする。
　本発明に係るバックログ管理装置は、スクラム開発におけるバックログを管理するバックログ管理装置であって、前記バックログ管理装置が、前記スクラム開発によるプロダクト作成のための必要項目である、複数のバックログを記憶する記憶部を有し、各前記バックログには、当該バックログを完成するための作業量を示すストーリーポイントと、当該バックログの作業の進捗に応じた段階が作業全体に対する割合で示される完成割合とを含む情報が記載されており、各前記バックログのストーリーポイントを合計し、合計ストーリーポイントを算出するストーリーポイント集計部と、各前記バックログにおいて、当該バックログのストーリーポイントと前記完成割合とを乗算し、その結果を各前記バックログについて集計し、進捗合計ストーリーポイントを算出する完成割合ストーリーポイント計算部と、を備えることを特徴とする。
　本発明によれば、１つのスプリントでバックログが完成しない開発プロセスの場合においても、ストーリーポイントの進捗状況を正確に把握することができる。
比較例に係るバックログ管理装置に登録されるバックログのデータ構成例を示す図である。 比較例に係るバックログ管理装置の構成を示すブロック図である。 比較例に係るバックログ管理装置によるバックログ管理処理の流れを示すフローチャートである。 本実施形態に係るバックログ管理装置の構成を示すブロック図である。 本実施形態に係るバックログ管理装置に登録されるバックログのデータ構成例を示す図である。 本実施形態に係るバックログ管理装置によるバックログ管理処理の流れを示すフローチャートである。 本実施形態に係るバックログ管理装置の機能を実現するコンピュータの一例を示すハードウェア構成図である。
　まず、従来技術で用いられるバックログ管理装置を、比較例として説明する。
　図１～図３は、本実施形態の比較例に係るバックログ管理装置５を説明するための図である。図１は、バックログ管理装置５に登録されるバックログ５００のデータ構成例を示す図である。図２は、比較例に係るバックログ管理装置５の構成を示すブロック図である。図３は、バックログ管理装置５によるバックログ管理処理の流れを示すフローチャートである。
　スクラム開発では、「バックログ」と呼ばれる、機能や要求、要望、修正などのプロダクトに必要なものをまとめたリストを作成し、開発期間の単位である「スプリント」とよばれるサイクル（例えば、１週間や２週間）を繰り返して開発を行う。例えば、ソフトウェア開発を行う場合には、最終的なプロダクト（ソフトウェア）を完成するために、通常１回か２回のスプリントで完成する複数のバックログが作成される。このバックログは、優先順位に基づき並べ替えられたり、開発途中で追加されたりすることもある。
　図１は、比較例に係るバックログ管理装置５（図２）に登録されるバックログ５００のデータ構成例を示す図である。
　このバックログ５００は、スクラム開発では、開発メンバーや、プロダクトオーナーと呼ばれる作成するプロダクト（ソフトウェア）の開発責任者等により作成され、バックログ管理装置５に登録されるものである。
　図１で示すように、バックログ５００には、ユーザーストーリー５１０、完成の定義５２０、受け入れ基準５３０、タスク一覧５４０、ストーリーポイント５５０およびステータス５６０の情報が格納される。図１のバックログ５００は、例として優先順位が「１」番目のバックログ「１」（バックログ５００＃１）を示している。
　ユーザーストーリー５１０には、ユーザの視点から、開発する機能やサービスを説明する文章が格納される。
　このユーザーストーリー５１０により、ユーザがどのような機能やサービスを求めているのかと、その理由が説明される。
　完成の定義５２０には、そのバックログ５００についての、機能要件や品質を満たすことを確認するための完成チェックリストが格納される。この完成チェックリストには、何をどこまでやれば「完成」とするかの定義が記載される。
　受け入れ基準５３０には、ユーザーストーリー５１０で定義した機能が提供する条件が定められる。
　例えば、金銭の支払いに関するソフトウェア開発のバックログ５００であれば、「支払いはクレジットと請求書の選択が可能」、「すべての必須項目を入力しないとフォームを送信できない」、「フォームを送信した後、ユーザと管理者に確認メールが送信される」等の条件が定められる。
　タスク一覧５４０には、ユーザーストーリー５１０を実現するための具体的なタスク（作業内容）が記載される。
　ストーリーポイント５５０には、そのバックログ５００についての開発担当チームにおける作業量（相対的な作業の見積量）が記載される。このストーリーポイント５５０が示す作業量は、絶対的な値ではなく、スクラム開発期間内の全体の作業量や、他のバックログ５００の作業量との関係で決定される相対的な値である。よって、このストーリーポイント５５０は、作業開始時に設定した値とは変更される場合もある。このストーリーポイント５５０を用いて、業務完了までの期間を予測したり、開発チームの業務の内容を評価したりすることができる。
　このストーリーポイント５５０は、開発メンバーや、プロダクト（ソフトウェア）の開発責任者等により設定され、バックログ５００に登録されるものである。また、このストーリーポイント５５０は、予め登録された値から、スクラム開発期間内の他のバックログ５００の進捗等を考慮して、他の値に更新されることもある。
　ステータス５６０は、そのバックログ５００の進捗の状態を格納するものであり、完成状態５６１と、完成スプリント番号５６２の情報を含んで構成される。
　完成状態５６１は、そのバックログ５００が完成の定義５２０に従って、ユーザーストーリー５１０が実現される状態であれば、「完成」が格納される。また、タスクが実施中だったり、未実施の場合には、「未完成」が格納される。なお、この完成状態５６１には、デフォルトとしては「未完成」が格納される。
　完成スプリント番号５６２は、そのバックログ５００が完成した場合に、その完成したときのスプリント番号が格納される。例えば、このバックログ５００＃１が、２番目のスプリントで完成した場合には、完成スプリント番号として、スプリント「２」が格納される。
　次に、比較例に係るバックログ管理装置５の構成について図２を参照して説明する。
　バックログ管理装置５は、バックログの進捗を管理する装置であり、バックログ管理部５０と、進捗管理部５１と、進捗情報記録部５２とを含んで構成される。
　バックログ管理部５０は、図１で示したバックログ５００が複数格納される。
　図２では、各バックログ５００のステータス５６０（完成状態５６１）と、ストーリーポイント５５０を抽出して記載している。例えば、バックログ「１」は、完成状態５６１が「完成」であり、そのバックログ「１」のストーリーポイント５５０が「１０」であることを示している。バックログ「２」は、完成状態５６１が「完成」であり、そのバックログ「２」のストーリーポイント５５０が「５」である。以下、バックログ「３」～「５」についても同様である。
　進捗管理部５１は、バックログ管理部５０に登録された各バックログ５００の進捗を管理する機能として、ストーリーポイント集計部５１１と、バックログ完成状態判定部５１２と、完成ストーリーポイント集計部５１３と、完成スプリント判定部５１４と、ベロシティ集計部５１５とを備える。
　ストーリーポイント集計部５１１は、バックログ管理部５０に登録された各バックログ５００のストーリーポイント５５０を合計し、合計ストーリーポイントを算出する。
　ストーリーポイント集計部５１１は、算出した合計ストーリーポイントを、進捗情報記録部５２内に、ストーリーポイント進捗情報２００Ａとして記録する。
　バックログ完成状態判定部５１２は、各バックログ５００について、ステータス５６０の完成状態５６１を参照し、そのバックログ５００の完成状態５６１が「完成」か否かを判定する。
　なお、バックログ５００の完成状態５６１は、そのバックログ５００のタスク一覧５４０で示されるタスクについて、完成の定義５２０に従って完成したことを開発メンバー等が確認することにより、「未完成」から「完成」に設定（登録）されるものである。
　完成ストーリーポイント集計部５１３は、各バックログ５００のうち、ステータス５６０の完成状態５６１が「完成」として登録されたバックログ５００のストーリーポイント５５０を集計し、完成合計ストーリーポイントを算出する。
　完成ストーリーポイント集計部５１３は、算出した完成合計ストーリーポイントを、進捗情報記録部５２内に、ストーリーポイント進捗情報２００Ａとして記録する。
　完成スプリント判定部５１４は、各バックログ５００のうち、完成状態５６１が「完成」のバックログについて、ステータス５６０の完成スプリント番号５６２を参照し、そのバックログ５００がどのスプリントで完成したのかを判定する。
　ベロシティ集計部５１５は、スプリントごとに、そのスプリントで完成したバックログ５００のストーリーポイント５５０を合計し、ベロシティを算出する。なお、ベロシティは、そのスプリントにおいて完成したバックログ５００のストーリーポイント５５０の合計値を意味する。
　ベロシティ集計部５１５は、スプリントごとに算出したベロシティを、進捗情報記録部５２のベロシティ情報３００Ａに記録する。
　図２においては、ベロシティ情報３００Ａとして、スプリント「１」のときベロシティ「１０」、スプリント「２」ときベロシティ「５」、スプリント「３」のときベロシティ「１５」であることを示している。
　次に、図３を参照して、比較例におけるバックログ管理処理の流れを説明する。
　バックログ管理装置５が実行する各バックログ５００の進捗を管理する計算処理は、例えば、各スプリントが終了した時点で実行される。
　なお、各スプリントが終了した時点で、バックログ管理部５０に登録された各バックログ５００のステータス５６０（完成状態５６１および完成スプリント番号５６２）が、開発メンバー等により更新されたものとする。
　バックログ管理装置５の進捗管理部５１は、ステップＳ１０～Ｓ１５までの処理を、バックログ管理部５０に登録したすべてのバックログ５００に対して繰り返す（ステップＳ１０：バックログ毎の計算）。
　まず、バックログ管理装置５のストーリーポイント集計部５１１は、バックログ５００のストーリーポイント５５０の情報を取得し、ストーリーポイント進捗情報２００Ａとしての合計ストーリーポイントに加算する（ステップＳ１１）。
　ストーリーポイント集計部５１１は、この処理をすべてのバックログ５００に対して繰り返すことにより、各バックログ５００のストーリーポイント５５０を合計し、合計ストーリーポイントを算出する。
　次に、バックログ完成状態判定部５１２は、バックログ５００について、ステータス５６０の完成状態５６１を参照し、そのバックログ５００の完成状態５６１が「完成」か否かを判定する（ステップＳ１２）。
　ここで、そのバックログ５００の完成状態５６１が「完成」でなければ（ステップＳ１２→Ｎｏ）、ステップＳ１５へ進む。一方、そのバックログの完成状態５６１が「完成」であれば（ステップＳ１２→Ｙｅｓ）、次のステップＳ１３へ進む。
　ステップＳ１３において、完成ストーリーポイント集計部５１３は、完成状態５６１が「完成」として登録されたバックログ５００のストーリーポイント５５０の情報を取得し、ストーリーポイント進捗情報２００Ａとしての完成合計ストーリーポイントに加算する。
　完成ストーリーポイント集計部５１３は、この処理を完成状態５６１が「完成」として登録されたバックログ５００すべてについて行い、ストーリーポイント５５０を合計し、完成合計ストーリーポイントを算出する。
　続いて、完成スプリント判定部５１４が、各バックログ５００のうち、完成状態５６１が「完成」のバックログ５００について、ステータス５６０の完成スプリント番号５６２を参照し、そのバックログ５００がどのスプリントで完成したのかを判定する。そして、ベロシティ集計部５１５が、そのスプリントで完成したバックログ５００のストーリーポイント５５０を、ベロシティ情報３００Ａの該当するスプリントのベロシティに加算する（ステップＳ１４）。
　ベロシティ集計部５１５は、この処理を、完成状態５６１が「完成」として登録されたバックログ５００すべてについて行い、スプリント毎にストーリーポイント５５０を合計し、ベロシティ情報３００Ａで示す、各スプリントのベロシティを算出する。
　そして、進捗管理部５１は、すべてのバックログ５００について、ステップＳ１１～Ｓ１４の処理を繰り返し（ステップＳ１５：バックログ毎の計算終了）、処理を終了する。
　このようにすることにより、比較例のバックログ管理装置５において、ストーリーポイント進捗情報２００Ａを参照することにより、バックログ５００全体の「合計ストーリーポイント」（図２では、「１００」）に対する、完了したバックログ５００のストーリーポイント５５０の合計である「完成合計ストーリーポイント」（図２では「３０」）を参照することにより、進捗状況を確認することができる。
　また、ベロシティ情報３００Ａを参照することにより、スプリント毎のベロシティの値を確認することができる。これにより、業務完了までの期間を予測したり、開発チームの業務の内容を評価したりすることができる。なお、業務完了までの期間の予測は、予定しているスプリントの合計のストーリーポイントと、過去のスプリントのベロシティとを用いて予測スプリント数を算出することにより行う。また、ベロシティに大きなばらつきがある場合には、作業工程や開発チームの見直しの検討が必要と評価され、一方、ベロシティが安定している場合や、上昇傾向にある場合には、開発チームが組織として成長していると評価される。このようにベロシティは、チームの状態を可視化するために利用される。
　しかしながら、上記したように、比較例のバックログ管理装置５では、バックログ５００が完成した場合に、「完成合計ストーリーポイント」にそのバックログ５００のストーリーポイント５５０が加算されるとともに、ベロシティ情報３００Ａの各スプリントのベロシティにもストーリーポイント５５０が加算されるものである。つまり、あるスプリントにおいて、バックログが完成しない場合には、たとえ、作業（タスク）が途中まで進んでいたとしても、進捗状況が変化しないものである。よって、開発の進捗を正確に把握できるものではなかった。
　スクラム開発においても、アジャイル開発のように、例えば、ＢＤ書やＦＤ書等のドキュメントを作成する場合があり、このように作業時間がかかる、つまり、スプリント１回では完成しない処理工程の進捗を正確に反映することが、比較例のバックログ管理装置５ではできないという課題であった。
　以下、この課題を解決する本実施形態に係るバックログ管理装置１について説明する。
≪本実施形態に係るバックログ管理装置≫
　本実施形態に係るバックログ管理装置１（後記する図４）は、バックログ１００（後記する図５）のステータスに完成割合を追加し、バックログ１００のストーリーポイントに完成割合の値を乗算して、ストーリーポイントの合計値の算出を行う。また、バックログ管理装置１は、スプリントごとの完成割合の進捗を考慮して、ベロシティの算出を行う。これにより、バックログ管理装置１は、１つのスプリントでバックログが完成しない場合においても、バックログの進捗状況を正確に把握することが可能となる。以下、詳細に説明する。
　図４は、本実施形態に係るバックログ管理装置１の構成を示すブロック図である。
　バックログ管理装置１は、図示を省略した、制御部、入出力部および記憶部を備えるコンピュータにより実現される（詳細は図７参照）。
　入出力部は、外部装置との間でバックログ１００の登録を受け付けたり、各種の設定変更に関する情報を受け付けたりする。
　この入出力部は、通信回線を介して情報の送受信を行う通信インタフェースと、図示を省略したキーボード等の入力装置やモニタ等の出力装置との間で情報の入出力を行う入出力インタフェースとから構成される。
　記憶部は、ハードディスクやフラッシュメモリ、ＲＡＭ（Random Access Memory）等により構成される。
　この記憶部には、制御部の各機能を実行させるためのプログラム（バックログ管理プログラム）や、制御部の処理に必要な情報が一時的に記憶される。また、この記憶部には、後記するバックログ１００（図５）を格納するバックログ管理部１０、および、ストーリーポイントの進捗に関する情報（ストーリーポイント進捗情報２００）やベロシティの情報（ベロシティ情報３００）を格納する進捗情報記録部１３が記憶される。
　図５は、本実施形態に係るバックログ管理装置１（図４）に登録されるバックログ１００のデータ構成例を示す図である。
　本実施形態におけるバックログ１００には、図５で示すように、ユーザーストーリー１１０、完成の定義１２０、受け入れ基準１３０、タスク一覧１４０、ストーリーポイント１５０およびステータス１６０の情報が格納される。このうち、ユーザーストーリー１１０、完成の定義１２０、受け入れ基準１３０、タスク一覧１４０、ストーリーポイント１５０の各情報は、図１で示した比較例のバックログ５００における、ユーザーストーリー５１０、完成の定義５２０、受け入れ基準５３０、タスク一覧５４０、ストーリーポイント５５０と同様の内容であるため、説明を省略する。
　本実施形態に係るバックログ１００は、比較例のバックログ５００（図１）のステータス５６０に格納される、完成状態５６１および完成スプリント番号５６２の代わりに、ステータス１６０に、完成割合１６１およびスプリント履歴情報１６２を格納する。
　完成割合１６１は、そのバックログ１００の作業（タクス）の進捗に応じた段階が作業全体に対する割合で示される情報である。
　例えば、完成割合１６１は、図５で示すように、「0：未着手」から「1.0：完了」までを作業内容に応じて複数の段階に分けた数値（割合）で示される。
　ここでは、「0：未着手」「0.1：ＢＤ完了」「0.3：ＦＤ完了」「0.4：Analyze完了」「0.7：Ｍ／ＵＴ完了」「0.9：ＩＴ完了」「1.0：完了」の７段階の完成割合で判定する例を示している。
　ここで、「0：未着手」は、そのバックログ１００のすべての作業（タスク）について実行していないことを意味し、全体の作業の０割が完成したことを示す。「0.1：ＢＤ完了」は、基本設計が完了した段階であることを意味し、全体の作業の１割が完成したことを示す。「0.3：ＦＤ完了」は、機能設計が完了した段階であることを意味し、全体の作業の３割が完成したことを示す。「0.4：Analyze完了」は、動作内容や処理の流れについてのプログラムの定義が決定した段階であることを意味し、全体の作業の４割が完成したことを示す。「0.7：Ｍ／ＵＴ（Make/Unit Test）完了」は、コーディング工程および単体テスト工程が完了した段階であることを意味し、全体の作業の７割が完成したことを示す。「0.9：ＩＴ（Integration Test）完了」は、結合テストが完了した段階であることを意味し、全体の作業の９割が完成したことを示す。「1.0：完成」は、そのバックログ１００のすべての作業の実行が完了したことを意味し、全体の作業の１０割が完成したことを示す。
　この完成割合１６１は、そのバックログ１００の開発メンバーや開発責任者等により、スプリント終了ごとに、作業の進捗に応じた段階の値（割合）が格納されるようにしてもよい。また、後記する完成割合判定部１２２が、タスク一覧１４０で示されるタスク（作業内容）がどこまで終了したかの登録を受け付け、その結果に応じた段階の値（割合）を登録するようにしてもよい。
　なお、完成割合１６１の段階は、上記した７段階に限定されず、プロダクト（ソフトウェア）開発の作業内容に応じて適宜設定される。
　スプリント履歴情報１６２には、そのバックログ１００において、スプリントごとに、スプリント開始時の完成割合と、スプリント終了時の完成割合とが格納される。
　例えば、図５で示すように、バックログ「１」（バックログ１００＃１）のスプリント履歴情報１６２として、１回目のスプリントであるスプリント「１」において、開始時の完成割合が「0：未着手」であり、終了時の完成割合が「0.3：ＦＤ完了」であることを示す「0～0.3」が格納される。また、２回目のスプリントであるスプリント「２」において、開始時の完成割合が「0.3：ＦＤ完了」であり、終了時の完成割合が「1.0：完成」であることを示す「0.3～1.0」が格納される。
　図４に戻り説明を続ける。制御部（図示省略）は、バックログ管理装置１が実行する処理の全般を司り、バックログ登録部１１と、進捗管理部１２とを備える。
　バックログ登録部１１は、バックログ１００の登録を外部から受け付け、バックログ管理部１０内に格納する。バックログ登録部１１は、開発途中において、新たなバックログ１００の登録を受け付けることもできる。
　また、バックログ登録部１１は、各バックログ１００のストーリーポイント１５０に変更があった場合には、その情報を受け付けて、そのバックログ１００の情報を更新する。
　さらに、バックログ登録部１１は、各バックログ１００のステータス１６０に記憶される完成割合１６１を変更する場合に、その変更情報を受け付け、そのバックログ１００の完成割合１６１を更新する。
　進捗管理部１２は、各バックログ１００の完成割合を踏まえた上で、進捗の合計となるストーリーポイント（進捗合計ストーリーポイント）や、ベロシティを算出する。この進捗管理部１２は、ストーリーポイント集計部１２１と、完成割合判定部１２２と、完成割合ストーリーポイント計算部１２３と、ベロシティ集計部１２４とを備える。
　ストーリーポイント集計部１２１は、バックログ管理部１０に登録された各バックログ１００のストーリーポイント１５０を合計し、「合計ストーリーポイント」を算出する。
　ストーリーポイント集計部１２１は、算出した合計ストーリーポイントを、進捗情報記録部１３内に、ストーリーポイント進捗情報２００として記録する。
　完成割合判定部１２２は、バックログ１００のステータス１６０の完成割合１６１を参照し、当該バックログ１００の完成割合を判定する。
　または、完成割合判定部１２２は、タスク一覧１４０に記載されたタスク（作業内容）がどこまで終了したかの登録を受け付け、その結果に基づきどの作業まで完了したのかを判定し、ステータス１６０の完成割合１６１に登録してもよい。
　なお、完成割合判定部１２２は、１つのスプリントが終了するごとに、そのバックログ１００において、そのスプリントにおける、スプリント開始時の完成割合と、スプリント終了時の完成割合とを、スプリント履歴情報１６２として、ステータス１６０に格納する。
　完成割合ストーリーポイント計算部１２３は、バックログ１００それぞれにおいて、バックログ１００に登録されたストーリーポイント１５０と完成割合１６１とを乗算し、その結果をすべてのバックログ１００で集計することにより、「進捗合計ストーリーポイント」を算出する。
　完成割合ストーリーポイント計算部１２３は、算出した進捗合計ストーリーポイントを、進捗情報記録部１３内に、ストーリーポイント進捗情報２００として記録する。
　ベロシティ集計部１２４は、各バックログ１００について、ステータス１６０のスプリント履歴情報１６２を参照し、スプリント毎に実行割合（そのバックログ１００の作業全体に対する、そのスプリント内で実行した作業の割合）を算出する。
　例えば、ベロシティ集計部１２４は、図５で示すスプリント履歴情報１６２を参照し、バックログ「１」のスプリント「１」における実行割合を「0.3」と算出する。また、ベロシティ集計部１２４は、バックログ「１」のスプリント「２」における実行割合を「0.7」（＝1.0-0.3）と算出する。
　そして、ベロシティ集計部１２４は、バックログ１００それぞれにおいて、スプリントごとに、そのバックログ１００に登録されたストーリーポイント１５０と実行割合とを乗算し、その結果を、すべてのバックログ１００についてスプリントごとに合計し、ベロシティを算出する。
　ベロシティ集計部１２４は、スプリントごとに算出したベロシティを、進捗情報記録部１３のベロシティ情報３００に記録する。
　図４においては、ベロシティ情報３００として、スプリント「１」のときベロシティ「１８．０」、スプリント「２」のときベロシティ「１７．５」、スプリント「３」のとき、ベロシティ「１４．５」であることを示している。
　＜バックログ管理装置の処理＞
　次に、図６を参照して、本実施形態に係るバックログ管理装置１が実行するバックログ管理処理の流れを説明する。
　バックログ管理装置１が実行する各バックログ１００の進捗を管理する計算処理は、例えば、各スプリントが終了した時点で実行される。これ以外にも、新しいバックログ１００がバックログ管理部１０に登録されたときや、各バックログ１００のいずれかのストーリーポイント１５０の値が変更されたときに実行してもよい。
　なお、ここでは、バックログ登録部１１が、バックログ１００の登録を外部から受け付け、図４で示すように、バックログ管理部１０内にバックログ「１」～「５」が格納されているものとする。
　バックログ管理装置１の進捗管理部１２は、ステップＳ１～Ｓ６までの処理を、バックログ管理部１０に登録したすべてのバックログ１００に対して繰り返す（ステップＳ１：バックログ毎の計算）。
　まず、バックログ管理装置１のストーリーポイント集計部１２１は、バックログ１００のストーリーポイント１５０（図５）の情報を取得し、ストーリーポイント進捗情報２００としての合計ストーリーポイントに加算する（ステップＳ２）。
　ストーリーポイント集計部１２１は、この処理をすべてのバックログ１００に対して繰り返すことにより、各バックログ１００のストーリーポイント１５０を合計し、合計ストーリーポイントを算出する。
　次に、完成割合判定部１２２は、バックログ１００のステータス１６０の完成割合１５１を参照し、当該バックログ１００の完成割合を判定する（ステップＳ３）。
　また、完成割合判定部１２２は、１つのスプリントが終了するごとに、そのバックログ１００において、そのスプリントにおける、スプリント開始時の完成割合と、スプリント終了時の完成割合とを、スプリント履歴情報１６２として、ステータス１６０に格納する。
　続いて、完成割合ストーリーポイント計算部１２３は、バックログ１００に登録されたストーリーポイント１５０と、バックログ１００の完成割合１６１とを乗算し、その結果をストーリーポイント進捗情報２００としての進捗合計ストーリーポイントに加算する（ステップＳ４）。
　完成割合ストーリーポイント計算部１２３は、この処理をすべてのバックログ１００に対して繰り返すことにより、各バックログ１００の完成割合１６１を考慮した上でストーリーポイント１５０を合計し、進捗合計ストーリーポイントを算出することができる。
　完成割合ストーリーポイント計算部１２３は、算出した進捗合計ストーリーポイントを、進捗情報記録部１３内に、ストーリーポイント進捗情報２００として記録する。
　次に、ベロシティ集計部１２４は、各バックログ１００について、ステータス１６０のスプリント履歴情報１６２を参照し、スプリント毎に実行割合（そのバックログ１００の作業全体に対する、そのスプリント内で実行した作業の割合）を算出する。
　そして、ベロシティ集計部１２４は、バックログ１００それぞれにおいて、スプリントごとに、そのバックログ１００に登録されたストーリーポイント１５０と実行割合とを乗算し、その結果を、ベロシティ情報３００の該当するスプリントのベロシティに加算する（ステップＳ５）。
　ベロシティ集計部１２４は、この処理を、バックログ１００すべてについて行い、スプリントごとにストーリーポイントを合計し、ベロシティ情報３００で示す、各スプリントのベロシティを算出する。
　そして、進捗管理部１２は、すべてのバックログ１００について、ステップＳ２～Ｓ５の処理を繰り返し（ステップＳ６：バックログ毎の計算終了）、処理を終了する。
　このようにすることにより、本実施形態に係るバックログ管理装置１において、ストーリーポイント進捗情報２００を参照することにより、バックログ１００全体の「合計ストーリーポイント」（図４では「１００」）に対する、「進捗合計ストーリーポイント」（図４では「５０」）を確認することにより、より正確に現時点での進捗状況を確認することができる。
　また、ベロシティ情報３００を参照することにより、スプリント毎のより正確なベロシティの値を確認することができる。よって、業務完了までの期間を予測や、開発チームの業務内容の評価を、より正確に行うことができる。
＜ハードウェア構成＞
　本実施形態に係るバックログ管理装置１は、例えば図７で示すような構成のコンピュータ９００によって実現される。
　図７は、本実施形態に係るバックログ管理装置１の機能を実現するコンピュータ９００の一例を示すハードウェア構成図である。コンピュータ９００は、ＣＰＵ９０１、ＲＯＭ（Read Only Memory）９０２、ＲＡＭ９０３、ＨＤＤ（Hard Disk Drive）９０４、入出力Ｉ／Ｆ（Interface）９０５、通信Ｉ／Ｆ９０６およびメディアＩ／Ｆ９０７を有する。
　ＣＰＵ９０１は、ＲＯＭ９０２またはＨＤＤ９０４に記憶されたプログラム（バックログ管理プログラム）に基づき作動し、制御部（バックログ登録部１１，進捗管理部１２）（図４）による制御を行う。ＲＯＭ９０２は、コンピュータ９００の起動時にＣＰＵ９０１により実行されるブートプログラムや、コンピュータ９００のハードウェアに係るプログラム等を記憶する。
　ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、マウスやキーボード等の入力装置９１０、および、ディスプレイやプリンタ等の出力装置９１１を制御する。ＣＰＵ９０１は、入出力Ｉ／Ｆ９０５を介して、入力装置９１０からデータを取得するともに、生成したデータを出力装置９１１へ出力する。なお、プロセッサとしてＣＰＵ９０１とともに、ＧＰＵ（Graphics Processing Unit）等を用いても良い。
　ＨＤＤ９０４は、ＣＰＵ９０１により実行されるプログラムおよび当該プログラムによって使用されるデータ等を記憶する。通信Ｉ／Ｆ９０６は、通信網（例えば、ＮＷ（Network）９２０）を介して他の装置からデータを受信してＣＰＵ９０１へ出力し、また、ＣＰＵ９０１が生成したデータを、通信網を介して他の装置へ送信する。
　メディアＩ／Ｆ９０７は、記録媒体９１２に格納されたプログラム（バックログ管理プログラム）またはデータを読み取り、ＲＡＭ９０３を介してＣＰＵ９０１へ出力する。ＣＰＵ９０１は、目的の処理に係るプログラムを、メディアＩ／Ｆ９０７を介して記録媒体９１２からＲＡＭ９０３上にロードし、ロードしたプログラムを実行する。記録媒体９１２は、ＤＶＤ（Digital Versatile Disc）、ＰＤ（Phase change rewritable Disk）等の光学記録媒体、ＭＯ（Magneto Optical disk）等の光磁気記録媒体、磁気記録媒体、半導体メモリ等である。
　例えば、コンピュータ９００が本発明のバックログ管理装置１として機能する場合、コンピュータ９００のＣＰＵ９０１は、ＲＡＭ９０３上にロードされたプログラムを実行することにより、バックログ管理プログラムの機能を実現する。また、ＨＤＤ９０４には、ＲＡＭ９０３内のデータが記憶される。ＣＰＵ９０１は、目的の処理に係るプログラムを記録媒体９１２から読み取って実行する。この他、ＣＰＵ９０１は、他の装置から通信網（ＮＷ９２０）を介して目的の処理に係るプログラムを読み込んでもよい。
＜効果＞
　以下、本発明に係るバックログ管理装置等の効果について説明する。
　本発明に係るバックログ管理装置は、スクラム開発におけるバックログ１００を管理するバックログ管理装置１であって、バックログ管理装置１は、スクラム開発によるプロダクト作成のための必要項目である、複数のバックログ１００を記憶する記憶部を有し、各バックログ１００には、当該バックログ１００を完成するための作業量を示すストーリーポイント１５０と、当該バックログ１００の作業の進捗に応じた段階が作業全体に対する割合で示される完成割合１６１とを含む情報が記載されており、各バックログ１００のストーリーポイント１５０を合計し、合計ストーリーポイントを算出するストーリーポイント集計部１２１と、各バックログ１００において、当該バックログ１００のストーリーポイント１５０と完成割合１６１とを乗算し、その結果を各バックログ１００について集計し、進捗合計ストーリーポイントを算出する完成割合ストーリーポイント計算部１２３と、を備えることを特徴とする。
　このように、バックログ管理装置１は、完成割合を用いて、進捗合計ストーリーポイントを算出することができる。よって、バックログ管理装置１は、１つのスプリントでバックログが完成しない開発プロセスの場合においても、ストーリーポイントの進捗状況を正確に把握することができる。
　特に、ソフトウェアの開発プロセスにおいて、例えば、基本設計書や機能設計書などのドキュメントを作成するようなスクラム開発の場合に、１つのスプリントで作業が完成しない場合でも、ストーリーポイントの進捗状況を正確に把握することができる。バックログは、工程ごとには作成されず、ある機能を完成させるまでの一連の作業に対して作成することが基本となるため、バックログの完成割合を用いて進捗を算出することにより、従来技術よりも正確な状況把握が可能となる。
　また、バックログ管理装置１において、各バックログ１００には、繰り返される開発期間の単位であるスプリントの開始時の完成割合および終了時の完成割合が、スプリントごとにスプリント履歴情報１６２として記憶されており、スプリント履歴情報１６２を参照し、バックログ１００の作業全体に対するスプリント内で実行した作業の割合である実行割合をスプリント毎に算出し、当該バックログ１００のストーリーポイントと実行割合とを乗算し、その結果を各バックログ１００についてスプリント毎に合計して得た値を、スプリント毎のベロシティとして算出するベロシティ集計部１２４を、さらに備えることを特徴とする。
　このように、バックログ管理装置１は、スプリント履歴情報を参照して、スプリント内で実行した作業の割合である実行割合をスプリント毎に算出し、スプリント毎のベロシティを算出することができる。よって、バックログ管理装置１は、１つのスプリントでバックログが完成しない開発プロセスの場合においても、スプリント毎のベロシティを作業の進捗に応じて正確に把握することができる。
　また、バックログ管理装置１において、完成割合は、未着手の段階を0、基本設計が完了した段階を0.1、機能設計が完了した段階を0.3、プログラム定義が完了したことを示すAnalyze完了の段階を0.4、コーディングおよび単体テストが完了したことを示すＭ／ＵＴ（Make/Unit Test）完了の段階を0.7、結合テストが完了したことを示すＩＴ（Integration Test）完了の段階を0.9、すべての作業が完成した段階を1.0、とすることを特徴とする。
　このようにすることで、ソフトウェアの開発プロセスにおいて、例えば、基本設計書や機能設計書などのドキュメントを作成する作業（作業完成に時間がかかるもの）を含む場合においても、現実の開発プロセスにおいてかかる作業量に応じた割合で、完成割合を設定することができる。よって、バックログ管理装置１は、より正確に進捗状況を把握することが可能となる。
　なお、本発明は、以上説明した実施形態に限定されるものではなく、多くの変形が本発明の技術的思想内で当分野において通常の知識を有する者により可能である。
　１　　　バックログ管理装置
　１０　　バックログ管理部
　１１　　バックログ登録部
　１２　　進捗管理部
　１３　　進捗情報記録部
　１００　バックログ
　１２１　ストーリーポイント集計部
　１２２　完成割合判定部
　１２３　完成割合ストーリーポイント計算部
　１２４　ベロシティ集計部
　２００　ストーリーポイント進捗情報
　３００　ベロシティ情報

Claims (7)

  1. 　スクラム開発におけるバックログを管理するバックログ管理装置であって、
    　前記バックログ管理装置は、
    　前記スクラム開発によるプロダクト作成のための必要項目である、複数のバックログを記憶する記憶部を有し、
    　各前記バックログには、当該バックログを完成するための作業量を示すストーリーポイントと、当該バックログの作業の進捗に応じた段階が作業全体に対する割合で示される完成割合とを含む情報が記載されており、
    　各前記バックログのストーリーポイントを合計し、合計ストーリーポイントを算出するストーリーポイント集計部と、
    　各前記バックログにおいて、当該バックログのストーリーポイントと前記完成割合とを乗算し、その結果を各前記バックログについて集計し、進捗合計ストーリーポイントを算出する完成割合ストーリーポイント計算部と、
    　を備えることを特徴とするバックログ管理装置。
  2. 　各前記バックログには、繰り返される開発期間の単位であるスプリントの開始時の前記完成割合および終了時の前記完成割合が、前記スプリントごとにスプリント履歴情報として記憶されており、
    　前記スプリント履歴情報を参照し、前記バックログの作業全体に対するスプリント内で実行した作業の割合である実行割合を前記スプリント毎に算出し、当該バックログのストーリーポイントと前記実行割合とを乗算し、その結果を各前記バックログについてスプリント毎に合計して得た値を、スプリント毎のベロシティとして算出するベロシティ集計部を、さらに備えること
    　を特徴とする請求項１に記載のバックログ管理装置。
  3. 　前記完成割合は、未着手の段階を0、基本設計が完了した段階を0.1、機能設計が完了した段階を0.3、プログラム定義が完了したことを示すAnalyze完了の段階を0.4、コーディングおよび単体テストが完了したことを示すＭ／ＵＴ（Make/Unit Test）完了の段階を0.7、結合テストが完了したことを示すＩＴ（Integration Test）完了の段階を0.9、すべての作業が完成した段階を1.0、とすること
    　を特徴とする請求項１または請求項２に記載のバックログ管理装置。
  4. 　スクラム開発におけるバックログを管理するバックログ管理装置のバックログ管理方法であって、
    　前記バックログ管理装置は、
    　前記スクラム開発によるプロダクト作成のための必要項目である、複数のバックログを記憶する記憶部を有し、
    　各前記バックログには、当該バックログを完成するための作業量を示すストーリーポイントと、当該バックログの作業の進捗に応じた段階が作業全体に対する割合で示される完成割合とを含む情報が記載されており、
    　各前記バックログのストーリーポイントを合計し、合計ストーリーポイントを算出するステップと、
    　各前記バックログにおいて、当該バックログのストーリーポイントと前記完成割合とを乗算し、その結果を各前記バックログについて集計し、進捗合計ストーリーポイントを算出するステップと、
    　を実行することを特徴とするバックログ管理方法。
  5. 　各前記バックログには、繰り返される開発期間の単位であるスプリントの開始時の前記完成割合および終了時の前記完成割合が、前記スプリントごとにスプリント履歴情報として記憶されており、
    　前記バックログ管理装置は、
    　前記スプリント履歴情報を参照し、前記バックログの作業全体に対するスプリント内で実行した作業の割合である実行割合を前記スプリント毎に算出し、当該バックログのストーリーポイントと前記実行割合とを乗算し、その結果を各前記バックログについてスプリント毎に合計して得た値を、スプリント毎のベロシティとして算出するステップを、さらに実行すること
    　を特徴とする請求項４に記載のバックログ管理方法。
  6. 　前記完成割合は、未着手の段階を0、基本設計が完了した段階を0.1、機能設計が完了した段階を0.3、プログラム定義が完了したことを示すAnalyze完了の段階を0.4、コーディングおよび単体テストが完了したことを示すＭ／ＵＴ（Make/Unit Test）完了の段階を0.7、結合テストが完了したことを示すＩＴ（Integration Test）完了の段階を0.9、すべての作業が完成した段階を1.0、とすること
    　を特徴とする請求項４または請求項５に記載のバックログ管理方法。
  7. 　コンピュータを、請求項１または請求項２に記載のバックログ管理装置として機能させるためのバックログ管理プログラム。
PCT/JP2023/025373 2023-07-10 2023-07-10 バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム Ceased WO2025013147A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2023/025373 WO2025013147A1 (ja) 2023-07-10 2023-07-10 バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム
JP2025532242A JPWO2025013147A1 (ja) 2023-07-10 2023-07-10

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2023/025373 WO2025013147A1 (ja) 2023-07-10 2023-07-10 バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム

Publications (1)

Publication Number Publication Date
WO2025013147A1 true WO2025013147A1 (ja) 2025-01-16

Family

ID=94214860

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2023/025373 Ceased WO2025013147A1 (ja) 2023-07-10 2023-07-10 バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム

Country Status (2)

Country Link
JP (1) JPWO2025013147A1 (ja)
WO (1) WO2025013147A1 (ja)

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012146126A (ja) * 2011-01-12 2012-08-02 Ntt Data Corp 進捗管理支援装置、進捗管理支援方法、および進捗管理支援プログラム
JP2022108053A (ja) * 2021-01-12 2022-07-25 セイコーソリューションズ株式会社 クリティカルポイント監視装置、クリティカルポイント監視システム、クリティカルポイント監視方法、及びプログラム

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012146126A (ja) * 2011-01-12 2012-08-02 Ntt Data Corp 進捗管理支援装置、進捗管理支援方法、および進捗管理支援プログラム
JP2022108053A (ja) * 2021-01-12 2022-07-25 セイコーソリューションズ株式会社 クリティカルポイント監視装置、クリティカルポイント監視システム、クリティカルポイント監視方法、及びプログラム

Also Published As

Publication number Publication date
JPWO2025013147A1 (ja) 2025-01-16

Similar Documents

Publication Publication Date Title
Chua et al. Predicting change propagation and impact on design schedule due to external changes
CN115689485A (zh) 一种工程项目进度管理方法、装置、设备及可读介质
US20200311749A1 (en) System for Generating and Using a Stacked Prediction Model to Forecast Market Behavior
Vahabi et al. Impact of project briefing clarity on construction project performance
JP2008040760A (ja) 製品開発プロセスにおける設計変更の影響度分析装置および方法
US20230274207A1 (en) Work plan prediction
US10265614B2 (en) Managing challenge events
WO2014036027A1 (en) Predictive modeling: litigation decision analysis and optimization
Hong et al. Simulation-based schedule estimation model for ACS-based core wall construction of high-rise building
Kyösti et al. Prediction of service support costs for functional products
JP4211006B2 (ja) 進捗管理装置
JP6813827B2 (ja) 情報処理装置、情報処理システム、および情報処理プログラム
US8862493B2 (en) Simulator with user interface indicating parameter certainty
WO2025013147A1 (ja) バックログ管理装置、バックログ管理方法、および、バックログ管理プログラム
JP2019145007A (ja) 案件進捗予測装置および案件進捗予測システム
JP2015109056A (ja) 生産計画作成方法及び生産計画作成プログラム、並びに生産計画作成装置
JP4707376B2 (ja) 情報処理方法及びプログラム
Kapur et al. Simultaneous allocation of testing time and resources for a modular software
Gönül‐Sezer et al. A system dynamics model for the analysis of clinical laboratory productivity
KR102868416B1 (ko) 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획 정보를 제공하는 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체
KR102868422B1 (ko) 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획 정보를 제공하는 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체
KR102868431B1 (ko) 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획 정보를 제공하는 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체
Gupta et al. A comparison between various software cost estimation models
KR102868434B1 (ko) 디지털 생산 계획 정보를 제공하는 장치, 디지털 생산 계획 정보를 제공하는 방법 및 디지털 생산 계획 정보를 제공하는 컴퓨터로 실행 가능한 소프트웨어를 저장하는 저장 매체
JP7436854B2 (ja) 情報処理装置、制御方法、プログラム

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 23945027

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2025532242

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2025532242

Country of ref document: JP

NENP Non-entry into the national phase

Ref country code: DE