Submission Tracker, Issue Log Key to Agile Regulatory Publishing

Email this to someonePrint this pageShare on LinkedIn0Tweet about this on TwitterShare on Google+0

The following post is the fifth of six in GlobalSubmit’s Agile for Regulatory Submissions series. GlobalSubmit’s regulatory services team employs the Agile Methodology for submission projects. By instituting Agile principles, our team has been very successful in delivering high-quality submissions ahead of schedule while maintaining constant, clear lines of communication with sponsors. To date, 75% of the regulatory submission projects executed by GlobalSubmit have been completed ahead of schedule.

The content used in our Agile for Regulatory Submissions series is adapted from the original work of Ken Schwaber and Jeff Sutherland called the Scrum Guide under the Attribution Share-Alike license of Creative Commons. Our series, which differs from the original work in the industry it describes, end product of the Agile process and professionals involved in producing the end product, is available for license under the identical terms.

The artifacts associated with the Agile for Regulatory Submissions Methodology represent work or value to provide transparency and opportunities for inspection and adaptation. Artifacts as defined by Agile are specifically designed to maximize transparency of critical information so that everyone involved has an equal understanding of the artifact.

Regulatory Publishing Artifacts

Every document destined for submission to the Agency is recorded in the Submission Tracker. Documents present in the Submission Tracker will be grouped to form a submission deliverable. Documents are grouped to maximize publishing and QC efficiencies. Documents can be grouped for a variety of reasons. Most likely, documents are grouped either because they are a natural fit for review and include navigation aides to each other (i.e. all documents for one study) or the document work is similar as they were authored by the same provider. When questions arise as to how document publishing work should be completed, those issues are documented in the Issue Log.

Submission Tracker

The Submission Tracker is a list of every document that will be submitted to an Agency. The Submission Owner is responsible for the Submission Tracker, including its content, availability, table of contents sections, document production date, title, ordering and status of the document in the publishing process. For simple submissions (e.g. small amendments) the Submission Tracker could simply be a list of documents. Either way the Submission Tracker should have attributes that help estimate the publishing effort.

A Submission Tracker is never complete until the submission is sent to the Agency. The earliest version of it only includes the initially known and best-understood documents that will be submitted. The Submission Tracker evolves as the submission and document production evolves. Although it would be best for the Submission Tracker to be static, the Submission Tracker is dynamic; it constantly changes. As long as a submission has not been submitted, its Submission Tracker also exists.

When multiple Agile Teams work together on the same submission, one Submission Tracker is used to describe the upcoming work.

Submission Tracker refinement is the act of adding detail, estimates, and order to entries. Refinement is an ongoing process in which the Submission Owner and the Publishing Team collaborate on the details of Submission Tracker attributes. During Submission Tracker refinement, items are reviewed and revised. The Agile Team decides how and when refinement is done. Refinement usually consumes no more than 10% of the capacity of the Publishing Team.

The more information you have about a document (e.g. page count, scanned, submission ready) the easier it is to estimate the effort. Documents in the Submission Tracker that will occupy the Publishing Team for the upcoming Sprint are refined so that any one item can reasonably be “done” within the time allotted for the Sprint. Documents that can achieve a level of “done” within one Sprint are deemed “ready” for selection in a Sprint Planning session. Documents usually acquire this degree of transparency through refinement.

The Publishing Team is responsible for all estimates. The Submission Owner may influence the Publishing Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

Submission Deliverables

The Submission Owner consults the Submission Tracker in order to define submission deliverables. Submission deliverables are often organized based on what authors would like to review as one package. If the submission is small, the entire submission will constitute one deliverable.

If the submission is larger, it is broken up into logical sections like studies or drug substance sections. Often multiple sections or studies are grouped together to form one deliverable. Multiple deliverables can be scheduled for a Sprint or one deliverable can be scheduled for a Sprint. If one deliverable is too big to complete in one Sprint, that deliverable will need to be broken in to smaller deliverables. Submission deliverables need to be organized so that when they are complete a definition of “done” has been achieved.

Issue Log

While issues with the publishing effort are never welcome, they are a fact of life. Issues should be tracked and scheduled to be worked on in a Sprint. You should schedule enough time in a Sprint to allow each member of the Publishing Team to fix issues for the documents they published during that Sprint. Whenever possible, you should keep your Issue Log to a minimum. If your Issue Log gets too large, it would be a good idea to have an entire Sprint focusing on resolving issues.

Monitoring Progress to Reaching Goal

At any point in time, the total work remaining to reach a goal can be measured. The Submission Owner, at the very least, tracks the total work remaining during every Sprint Review. The Submission Owner compares the updated amount of work remaining to the amount of work remaining at previous Sprint Reviews to assess progress toward completing projected deliverables in time to meet the stated goal. The amount of work remaining is made available to all stakeholders.

Various practices for measuring trends have been used to forecast progress, like burn downs, burn ups, and cumulative flows. These tools have proven useful. However, these tools do not supplant the importance of empiricism. In complex environments, what will happen is unknown. Only what has happened may be used for forward-looking decisions.

Sprint Backlog

The Sprint Backlog is the set of documents entered in the Submission Tracker that’s selected for the Sprint. It also includes a plan for delivering the Submission Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast developed by the Publishing Team as to which documents will be published in the next increment and the work needed to deliver a “done” increment.

The Sprint Backlog makes visible all of the work that the Publishing Team identifies as necessary to meet the Sprint Goal.

The Sprint Backlog is a plan with enough detail that changes in progress can be understood in the Daily Stand Up Meeting. The Publishing Team modifies the Submission Tracker throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Publishing Team works through the plan and learns more about the work needed to achieve the Sprint Goal.

Monitoring Sprint Progress

At any point in time, the total work remaining in the Sprint Backlog can be measured. The Publishing Team tracks the amount of total work remaining, at least for every daily stand up meeting, in order to project the likelihood of achieving the Sprint Goal. By tracking the amount of work remaining throughout the Sprint, the Publishing Team can manage its progress.

©2015 GlobalSubmit. Offered for license under the Attribution Share-Alike license of Creative Commons, accessible at and also described in summary form at By utilizing this Agile for Regulatory Submissions content, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.

Author: Jason Rock

Jason Rock is a pioneer in the field of electronic submissions. Mr. Rock has an extensive background working with global life sciences companies and regulatory agencies to promote eCTD adoption through the development of advanced applications. The commercial software Mr. Rock originally developed, and continues to improve, in his role as Chief Technical Officer for GlobalSubmit, is used exclusively by the U.S. Food & Drug Administration to review and validate all eCTD submissions the FDA receives.

Share This Post On

Submit a Comment

%d bloggers like this: