Use Cases
This page outlines real-world scenarios to help you understand how and when the Auto Sprint Start Stop app triggers sprint actions. Each use case explains the conditions under which a sprint will or won’t start automatically, based on board setup, sprint configuration, and Jira behavior—helping you troubleshoot and configure with confidence.
🔹 Use Case 1: Two Sprints with the Same Start Date/Time
Scenario:
A project board contains two future sprints scheduled to start at the same time.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board
Sprint Configurations:
DT Sprint 01 – Start Date/Time: 08th Aug 2025, 10:00 AM
DT Sprint 02 – Start Date/Time: 08th Aug 2025, 10:00 AM
Expected Behavior:
When the system time reaches 08th Aug 2025, 10:00 AM, the app’s scheduler will trigger.
Only the topmost sprint (i.e., DT Sprint 01) will be started automatically. The app will not act on DT Sprint 02, as only one sprint can have the “Start Sprint” button active in the Jira UI at a time.
Why This Happens:
Jira’s native behavior allows only one active “Start Sprint” button per board. The app follows this rule and acts only on the top-positioned sprint in the list.
🔹 Use Case 2: Top Sprint Has a Later Start Date Than the One Below It
Scenario:
A sprint board has two future sprints. The sprint at the top of the list has a later start date/time than the sprint positioned below it.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board
Sprint Configurations:
DT Sprint 01 – Start Date/Time: 08th Aug 2025, 10:00 AM (Top)
DT Sprint 02 – Start Date/Time: 07th Aug 2025, 10:00 AM (Bottom)
Expected Behavior:
When the system time reaches 07th Aug 2025, 10:00 AM, the app will not start any sprint.
Instead, the app will wait until 08th Aug 2025, 10:00 AM to start DT Sprint 01, since it appears at the top.
Why This Happens:
Jira only activates the “Start Sprint” button for the topmost sprint in the backlog. The Auto Sprint Start Stop app follows this order. Even if a lower sprint has an earlier start date, it will be ignored if it’s not on top.
🔹 Use Case 3A: Board Not Configured in the App
Scenario:
A sprint is correctly created with a valid start date/time, but the board is not added to the Auto Sprint Start Stop configuration.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Not added to the app configuration)
Sprint: DT Sprint 01 – Start Date/Time: 08th Aug 2025, 10:00 AM
Expected Behavior:
The app will not start the sprint.
Why This Happens:
Only boards explicitly configured in the Auto Sprint Start Stop app are evaluated by the scheduler. Boards that aren’t added are ignored, regardless of sprint configuration.
🔹 Use Case 3B: Board Configured, but “Enable” Toggle is Off
Scenario:
The board is correctly added to the app configuration, but the “Enable” switch is turned off for sprint start automation.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured in app, “Enable” = Off)
Sprint: DT Sprint 01 – Start Date/Time: 08th Aug 2025, 10:00 AM
Expected Behavior:
The app will not start the sprint.
Why This Happens:
The “Enable” toggle acts as a control gate for automation. If it’s off, the app will skip the board, even if everything else is correctly configured.
🔹 Use Case 3C: Board Enabled, But Sprint Has No Tickets
Scenario:
The sprint is correctly created, the board is configured in the app, and the “Enable” switch is turned on. However, the sprint does not contain any issues.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured and Enabled)
Sprint: DT Sprint 01 – Start Date/Time: 08th Aug 2025, 10:00 AM
Ticket Count: 0
Expected Behavior:
The app will not start the sprint.
Why This Happens:
Auto Sprint Start Stop is designed to skip empty sprints. Even Jira doesn’t allow users to start an empty sprint.
🔹 Use Case 3D: Sprint Start Date/Time Is Missing
Scenario:
The board is properly configured in the app, the “Enable” toggle is turned on, and the sprint contains tickets; however, the start date/time is not set for the sprint.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured and Enabled)
Sprint: DT Sprint 01 – Start Date/Time: Not Set
Ticket Count: 1
Expected Behavior:
The app will not start the sprint.
Why This Happens:
Auto Sprint Start Stop uses the configured sprint start date/time in Jira to trigger automation. If this field is left blank, the app has no reference point to initiate the sprint, and the action is skipped by design.
🔹 Use Case 4: Sprint Start Date Added After Scheduled Time
Scenario:
A board is already configured and enabled in the Auto Sprint Start Stop app. Later, a sprint is updated with a start date/time that has already passed.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured and Enabled under Auto Sprint Starter)
Current System Time: 08th Aug 2025, 10:30 AM
Sprint: DT Sprint 01
Start Date/Time: 08th Aug 2025, 10:00 AM (added after 10:30 AM)
Expected Behavior:
The sprint will not start immediately upon updating the start date.
Instead, the app's scheduler will pick it up in the next cycle, and the sprint is expected to start at 11:00 AM.
Why This Happens:
The Auto Sprint Start Stop scheduler runs every 30 minutes. If a backdated start time is set after the system time has already passed it, the sprint will only start when the scheduler next evaluates it — not instantly.
🔹 Use Case 5: Future-Dated Sprint Start Time Is Honored
Scenario:
A board is configured and enabled in the Auto Sprint Start Stop app. A future sprint is later updated with a valid future start date/time.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured and Enabled)
Current System Time: 08th Aug 2025, 10:30 AM
Sprint: DT Sprint 01
Start Date/Time: 09th Aug 2025, 10:00 AM (added after 10:30 AM on 08th Aug)
Expected Behavior:
The app will not take any action immediately.
The sprint will be started automatically at the scheduled time: 09th Aug 2025, 10:00 AM, when the system time matches it.
Why This Happens:
Auto Sprint Start Stop respects the future start time configured in Jira. As long as the board is enabled and the sprint is valid, the app will trigger the start action exactly as per the scheduled time, using its 30-minute scheduler.
🔹 Use Case 6: Past-Dated Sprint Starts Immediately on Save
Scenario:
A sprint is configured with a past start date/time, and the board is added to the Auto Sprint Start Stop app after that. As soon as the board is saved in the app, the scheduler is triggered.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board
Current System Time: 08th Aug 2025, 10:30 AM
Sprint: DT Sprint 01
Start Date/Time: 08th Aug 2025, 10:00 AM (configured before 10:30 AM)
Board Configuration: Added to the app and enabled after 10:30 AM
Expected Behavior:
The sprint will start immediately upon clicking Save in the app.
Why This Happens:
Every time the Save button is clicked in Auto Sprint Start Stop, it triggers the scheduler immediately (in addition to the regular 30-minute cycle).
Since the sprint’s start date is in the past and the board is now authorized, the app starts the sprint right away.
🔹 Use Case 7: Overlapping Sprint Transitions (Same End and Start Time)
Scenario:
A board has two sprints where the end date/time of the current active sprint is exactly the same as the start date/time of the next sprint. The app handles this overlap automatically in a sequential manner.
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board
Sprint Timeline:
DT Sprint 01 – End Date/Time: 08th Aug 2025, 10:00 AM
DT Sprint 02 – Start Date/Time: 08th Aug 2025, 10:00 AM
Expected Behavior:
On 08th Aug 2025, 10:00 AM, the app will execute the following actions in order:
DT Sprint 01 will be closed.
Any open tickets from DT Sprint 01 will be moved to DT Sprint 02, based on the board’s closure configuration.
🚀 DT Sprint 02 will start.
Why This Happens:
Auto Sprint Start Stop intelligently handles back-to-back sprint transitions. When start and end times are identical, the app ensures the current sprint is closed first, open work is reallocated, and the next sprint begins immediately—ensuring a smooth and continuous delivery cycle without manual intervention.
🔹 Use Case 8: Sprint Start Delayed Due to API Timeout or Error
Scenario:
The board and sprint are configured correctly, with the correct start date/time and the board marked as “Enabled” in the app. However, the sprint does not start at the scheduled time due to a temporary Jira API issue (e.g., timeout, internal error, or rate limit).
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board (Configured and Enabled)
Sprint: DT Sprint 01
Start Date/Time: 08th Aug 2025, 10:00 AM
Expected Behavior:
The sprint does not start at 10:00 AM due to a temporary API failure from Jira.
However, on the next scheduler run (e.g., 10:30 AM or later), the app will recognize this as a backdated sprint and start it automatically when the API is responsive again.
Why This Happens:
The Auto Sprint Start Stop app depends on Jira APIs to perform actions. If the API call fails temporarily, the app will skip the action for that cycle. But as soon as the APIs recover, the app's scheduler picks up missed start actions and processes them as backdated sprints, ensuring continuity without manual intervention.
🔹 Use Case 9: Sprint from Another Board Started Due to incorrect Ticket Mapping
Scenario:
A sprint that was originally created on Board 2 appears at the top of Board 1 because a ticket from Board 1 has been incorrectly assigned to that sprint.
Even though Board 1 is the only one configured in the app, and Board 2 is not, the app ends up starting the sprint.
Example:
Sprint: P2-159-Sprint 01 – Originally created on Board 2 (Project Key P2)
Ticket: A Jira issue(P1-3) from Board 1(Project Key P1) is incorrectly mapped to P2-159-Sprint 01
App Configuration:
Board 1 – Configured and Enabled for start on the app UI
Board 2 – Not configured on the app
Expected Behavior:
When the system time reaches the scheduled start date/time of P2-159-Sprint 01, the app will start the sprint, even though it was created under Board 2, which is not configured on the app.
Why This Happens:
When the app queries sprints for Board 1 using the Jira API (/rest/agile/1.0/board/{boardId}/sprint), Jira returns any sprint that contains issues from that board, regardless of which board originally created the sprint.
Because P2-159-Sprint 01 is returned as a top-order sprint for Board 1, and Board 1 is configured in the app, the app proceeds to start the sprint.
🔹 Use Case 10: Sprint Stops at Scheduled End Time (Next Sprint Exists)
Scenario:
An active sprint is configured with a valid end date/time. The board is added under Auto Sprint Closure with "Move open tickets to: Next Sprint".
Example:
Project: Dependency Tracker App (DT)
Board: Dependency Tracker Board
Sprint: DT Sprint 01 – End Date/Time: 08th Aug 2025, 10:00 AM
Next Sprint: DT Sprint 02 exists
Expected Behavior:
At 10:00 AM, the app will:
Close DT Sprint 01
Move open tickets to DT Sprint 02
Why This Happens:
The app runs every 30 minutes and also on Save. If the end time matches system time, it will close the sprint and shift remaining work to the next available sprint.
🔹 Use Case 11: Sprint Stops Immediately When End Date Is in the Past
Scenario:
An active sprint has an end date/time that has already passed, and the board is just added under Auto Sprint Closure with "Move open tickets to: Backlog".
Example:
Current Time: 08th Aug 2025, 10:40 AM
Sprint End Time: 08th Aug 2025, 10:00 AM
Save clicked at: 10:40 AM
Expected Behavior:
The sprint is closed immediately, and open tickets are moved to the Backlog.
Why This Happens:
The app treats this as a backdated sprint, and the Save action triggers the scheduler, ensuring missed closures are executed right away.
🔹 Use Case 12: No Future Sprint → App Creates "Auto Custom Sprint"
Scenario:
Sprint ends as scheduled, and “Move open tickets to: Next Sprint” is selected, but no future sprint exists.
Expected Behavior:
The app will:
Close the active sprint
Create a new sprint titled “Auto Custom Sprint”
Move open issues into it
Why This Happens:
The app intelligently creates a placeholder sprint if no next sprint exists—ensuring that work is not lost. Users are encouraged to rename it before starting it.
🔹 Use Case 13: Project with Multiple Boards
Project Name: Core Prod
Project Key: PROD
Board Configured:
Core Prod Main
Core Prod 1
Core Prod 2
Core Prod 3
Board Filters:
Core Prod Main: project = "Core Product" ORDER BY key ASC
Core Prod 1: project = "Core Product" and key <= prod-100
Core Prod 2: project = "Core Product" and key > prod-100 AND key <=prod-200
Core Prod 3: project = "Core Product" and key >prod-200
Note: The main board aggregates all issues from the three sub-boards. However, there is no overlap between issues across sub-boards due to the specific filter configurations. For example, PROD-1 appears only on Core Prod 1 and not on the others, ensuring no duplication or conflicting references.
Sprint Setup:
Created two sprints (top-order and second-order) on each sub-board. All six sprints appeared on the Core Prod Main board (as expected, since it is aggregating data due the filter configuration).
Note: On the sub-boards, there was no blue text displayed next to any sprint names, indicating that sprint-to-issue linking is correct. The Core Prod Main board did display blue text next to sprint names — which is expected and acceptable in this context, as it acts only as a reporting/view layer. If you notice blue text displayed next to sprint names on your sub-boards, it’s worth reviewing. This typically indicates that a ticket from one board or project is linked to a sprint belonging to a different board or project.
App configuration:
On the Auto Sprint Start Stop app, only the sub-boards should be configured — not the main board — as actionable sprints reside on the sub-boards. The main board should not be used as the source of sprint execution, as it may lead to permission or sprint resolution issues.
Ideally, a 'Start' button should only appear once per board (in this case, sub-board) next to the top order sprint. However, if you see it for multiple sprints within a sub-board, it could simply mean incorrect linking, which would certainly impact Sprint Start/Stop operations via the app.
NOTE: Sites with ‘Parallel Sprint' enabled may also see a start button with multiple sprints. However, Auto Sprint Start Stop doesn’t support the Parallel Sprint feature.