Sprint Analytics

Sprint Analytics provides visual charts and metrics that reveal how work progresses through your iteration. Burndown charts, burnup charts, and distribution breakdowns transform raw task data into actionable insights.

The Problem This Solves

Looking at a task board tells you current state, but not trajectory. You cannot see whether you are ahead of schedule, falling behind, or experiencing scope creep. Without analytics, sprint reviews become guesswork: "I think we did okay" instead of "Here's exactly what happened."

Sprint Analytics converts your task history into charts that show patterns, problems, and progress. Make data-informed decisions during the sprint and conduct meaningful retrospectives after.

What You Are Looking At

The Analytics tab displays a dashboard of sprint metrics. At the top, a KPI bar shows key numbers at a glance. Below that, charts visualize task completion patterns. Distribution breakdowns reveal how work divides across types, members, and effort levels.

Note: Sprint Analytics is a Pro feature. A badge indicates when subscription upgrade is required.

KPI Stats Bar

The top row displays six key metrics:

Total Tasks: Complete count of tasks assigned to this sprint, regardless of status.

Completed: Number of tasks in "done" workflow states. Compare to total for completion ratio.

Progress: Percentage of tasks completed. Calculated as (completed / total) × 100.

Story Points: Sum of effort points assigned to sprint tasks. Only populated if your project uses point estimation.

Worked Hours: Total time logged against tasks in this sprint. Requires time tracking to be active.

Duration: Number of days in the sprint based on start and end dates.

These metrics update in real-time as tasks change status or time is logged.

Burndown Chart

The burndown chart shows remaining work over time. The Y-axis represents tasks (or points) remaining. The X-axis represents time from sprint start to end.

Ideal line: A diagonal line from total work at sprint start to zero at sprint end. This represents perfectly linear progress.

Actual line: Your real remaining work over time. Shows how progress compares to ideal.

Reading the chart:

• Line above ideal: Behind schedule. More work remains than expected.
• Line below ideal: Ahead of schedule. Work is completing faster than planned.
• Line matches ideal: On track for planned completion.
• Flat sections: No tasks completed during that period.
• Upward spikes: Scope added mid-sprint (tasks added or reopened).

Burnup Chart

The burnup chart complements burndown by showing completed work accumulating over time.

Scope line: Total sprint scope (all tasks assigned). A flat line means stable scope. Rising line means tasks are being added.

Completed line: Cumulative tasks finished over time. Should rise steadily toward the scope line.

Reading the chart:

• Completed approaching scope: Sprint will complete on time.
• Completed flat while scope rises: Scope creep outpacing delivery.
• Completed rising faster than scope: Team is ahead, or scope is reducing.
• Gap at sprint end: Work that did not get done (the remaining tasks).

Burnup is particularly useful when scope changes frequently, as it shows both completion progress and scope expansion simultaneously.

Task Type Distribution

This breakdown shows how sprint work divides across task types (Bug, Feature, Improvement, etc.).

For each type:

• Color indicator: Matches the type's configured color
• Type name: The task type label
• Count: Number of tasks of this type
• Percentage: Share of total sprint tasks
• Progress bar: Visual representation of percentage

Use cases:

• Identify bug-heavy sprints that may indicate quality issues
• Track feature versus maintenance ratios
• Ensure balanced work distribution

Team Member Distribution

This breakdown shows how tasks distribute across team members.

For each member:

• Avatar: Team member's profile image
• Name: Team member's name
• Count: Tasks assigned to this member
• Percentage: Share of total assigned tasks
• Progress bar: Visual representation of percentage

Use cases:

• Identify unbalanced workloads
• Find over-allocated or under-utilized team members
• Ensure equitable distribution during planning

Note: Tasks can have multiple assignees, so total assignments may exceed total tasks.

Effort Distribution

If your project uses effort or priority levels, this breakdown shows sprint work by effort category.

For each effort level:

• Color indicator: Effort level's configured color
• Level name: The effort category label
• Count: Tasks at this effort level
• Percentage: Share of total sprint tasks

Use cases:

• Verify appropriate mix of complex and simple work
• Ensure sprint does not contain only difficult tasks
• Track effort estimation patterns

Daily Activity Timeline

A timeline view may show task completions per day throughout the sprint:

• Bars or markers: Indicate tasks completed each day
• Patterns: Reveal work rhythm (steady versus end-loaded)
• Gaps: Days with no completions worth investigating

Use cases:

• Identify problematic patterns (all work completing last day)
• See how weekends or holidays affect progress
• Correlate with external events affecting productivity

Velocity Comparison

If available, velocity charts compare this sprint's throughput to historical sprints:

• Current sprint: Tasks or points completed
• Average velocity: Historical mean
• Trend line: Direction of velocity over recent sprints

Use cases:

• Understand capacity for future planning
• Identify improving or declining team performance
• Set realistic expectations for upcoming sprints

Refreshing Data

Click the refresh button in the sub-header to reload all analytics data. Use this when:

• Tasks have recently changed status
• You want the latest numbers during a meeting
• Charts seem stale or outdated

A loading indicator appears while data refreshes.

Using Analytics for Retrospectives

Analytics provide objective data for sprint retrospectives:

1. Review burndown shape: Was progress steady or end-loaded?
2. Check for scope creep: Did burnup show expanding scope?
3. Examine distributions: Was workload balanced? Were types as expected?
4. Compare velocity: How does this sprint compare to recent history?

Ground discussions in data rather than impressions. "We felt busy" becomes "We completed 23 tasks, 5 above average, but 8 were added mid-sprint."

Pro Tips

• Daily check-ins: Review burndown briefly each day to catch problems early
• Screenshot for documentation: Capture charts at sprint end for historical records
• Combine with qualitative data: Charts show what happened; team discussions explain why
• Watch for patterns: Consistent end-loading may indicate estimation or planning issues

How to Report a Problem or Request a Feature

Your feedback matters. Here is how to share it:

If charts display incorrectly, data seems wrong, or you want additional metrics, we want to hear about it.

In the Sidebar, click on Support Tickets and open a ticket for the problem. Everything is interactive and fast through the GitScrum Studio platform.

Create Sprint

The Create Sprint modal provides a streamlined interface for setting up new sprint iterations. Define your sprint timeline, goals, and initial status in seconds, then start assigning work to the new sprint.

The Problem This Solves

Starting a new sprint should take moments, not meetings. You need to capture the essential sprint parameters: what period it covers, what you aim to achieve, and what status it begins in. Everything else can be refined as planning progresses.

The Create Sprint modal focuses on these essentials while remaining flexible enough for teams with different planning styles.

What You Are Looking At

The Create Sprint modal appears as a centered dialog with a clean, focused interface. The header shows a project selector, followed by input fields for sprint title and goals. Below that, inline options provide status and date selectors displayed compactly in a single row.

Opening the Create Sprint Modal

You can open the Create Sprint modal from multiple locations:

From the Sprint List:

• Click the "New Sprint" or "+" button in the sprint list view

From the Global Quick Create:

• Use the global quick create menu and select Sprint
• Use keyboard shortcuts if configured

Context-aware creation: When you open the modal from within a specific project, the project selection automatically populates. This saves time when creating multiple sprints in the same project.

Project Selection

Before creating a sprint, select which project it belongs to. The project selector appears in the modal header.

If you have access to multiple workspaces: First select a workspace using the dropdown. After selecting a workspace, the project list updates to show projects in that workspace.

If you opened the modal from a project context: The project pre-fills automatically. You can still change it if needed.

Click a project name in the list to select it. A checkmark indicates the current selection.

Sprint Title

The title field accepts a name for your sprint. Good sprint titles help team members quickly identify iterations:

Effective naming patterns:

• Sequential: "Sprint 14", "Sprint 15"
• Date-based: "Sprint W23" (week 23), "Sprint Mar-1"
• Theme-based: "Sprint: User Authentication", "Sprint: Performance"
• Combined: "Sprint 14: API Refactor"

The title appears throughout the interface wherever this sprint is referenced. Keep it concise but distinctive enough to identify at a glance.

Sprint Goals (Description)

The goals field captures what the team aims to achieve during this sprint. Write goals in outcome-oriented language:

Strong goals:

• "Users can reset their passwords via email"
• "API response times under 200ms for all endpoints"
• "Complete onboarding flow testing"

Weak goals:

• "Work on tasks"
• "Fix bugs"
• "Make progress"

Goals provide focus during the sprint. When choosing which tasks to add or whether to accept new work mid-sprint, reference the goals: "Does this help us achieve our stated objectives?"

Leave this field empty if your team prefers to define goals separately or does not use sprint goals.

Sprint Status

The status dropdown shows available sprint statuses configured for your project. Select the starting status for this sprint:

Common initial statuses:

• Planning: Sprint is being prepared, work is being identified
• Ready: Sprint is planned and ready to begin
• Active: Sprint has started and work is in progress

Your project may have different or additional statuses. Select the status that matches where this sprint begins in your workflow.

Sprint Dates

Two date pickers define the sprint timeline:

Start Date: When the sprint begins. Tasks become "active" from this date for tracking purposes.

End Date: When the sprint concludes. This date drives burndown calculations and deadline tracking.

Click each date field to open a calendar picker. Select a date by clicking it in the calendar.

Duration indicator: When both dates are selected, the modal shows the calculated duration in days. This helps verify you have selected the intended timeframe.

Tips for date selection:

• Align with your team's schedule (start on Mondays, end on Fridays)
• Account for holidays or known absences
• Maintain consistent sprint length for velocity comparisons

Creating the Sprint

Click the confirm button to create the sprint. The system validates that you have:

• Selected a project
• Provided a sprint title
• Selected valid dates

If any required information is missing, the create button remains disabled.

Upon successful creation, the modal shows a success confirmation with options to:

• Go to Sprint: Navigate directly to the new sprint's board view
• Create Another: Stay in the modal with cleared fields to create another sprint

After Creating a Sprint

The new sprint appears in your project's sprint list and becomes available for task assignment. Next steps typically include:

1. Refine goals if you wrote placeholder text
2. Assign tasks to the sprint from backlog or by creating new tasks
3. Review capacity based on team availability during the sprint dates
4. Communicate the sprint plan to stakeholders

Creating Multiple Sprints

If you plan sprints in advance, use "Create Another" to set up multiple sprints in sequence:

1. Create Sprint 14 with dates for week 1-2
2. Click "Create Another"
3. Create Sprint 15 with dates for week 3-4
4. Continue as needed

This approach helps teams plan several iterations ahead while maintaining consistent naming and date progression.

Keyboard Navigation

The modal supports standard keyboard navigation:

• Tab: Move between fields
• Enter: In title field, moves to next field. On confirm button, creates the sprint.
• Escape: Close the modal without creating

Error Handling

If the creation request fails (network issues, validation problems, or permissions errors), the modal displays an error message. Your entered data remains in the form so you can retry without re-entering information.

Common issues:

• Duplicate names: Some projects prevent duplicate sprint titles
• Invalid dates: End date must be after start date
• Permissions: You may lack permission to create sprints in the selected project

Pro Tips

• Sprint templates: Note your preferred naming pattern, typical duration, and standard goals. Apply consistently across sprints.

• Buffer time: If your team consistently needs a few days after sprint end for wrap-up, factor that into your date selection.

• Goal specificity: The more specific your goals, the easier to evaluate sprint success. "Improve performance" is hard to measure; "Reduce load time to under 2 seconds" is clear.

How to Report a Problem or Request a Feature

Your feedback matters. Here is how to share it:

If the sprint creation process could be improved or you encounter issues, we want to know.

In the Sidebar, click on Support Tickets and open a ticket for the problem. Everything is interactive and fast through the GitScrum Studio platform.

Sprint Goals

Sprint goals define what the team aims to achieve during an iteration. More than a list of tasks, goals describe the outcomes that make a sprint successful. They provide focus when prioritizing work and evaluating results.

The Problem This Solves

A sprint full of tasks but no clear purpose leads to scattered effort. Team members complete work without understanding how it connects to larger objectives. At sprint end, nobody can confidently say whether the sprint succeeded.

Sprint goals transform a task list into a mission. When everyone understands the target outcome, decisions become easier: "Does this task help us achieve our goal?" drives prioritization, scope management, and daily focus.

What You Are Looking At

The Sprint Goals section appears in the Details tab of any sprint. It displays the current goal text with rich formatting support. An edit button opens a modal where you can modify the goal content.

Viewing Sprint Goals

Navigate to any sprint and select the Details tab. The Sprint Goal section shows:

• The goal title header
• Formatted goal content (supports rich text)
• An Edit button for users with appropriate permissions

If no goal has been set, the section displays placeholder text indicating no acceptance criteria provided.

Editing Sprint Goals

To edit sprint goals:

1. Navigate to the sprint's Details tab
2. Click the "Edit" button in the Sprint Goal header
3. The goal editor modal opens with the current content
4. Modify the goal text using the rich text editor
5. Click "Confirm" to save changes

The editor supports:

• Bold, italic, underline: Emphasize key phrases
• Headers: Structure longer goals with sections
• Lists: Bullet points and numbered lists for multiple objectives
• Code blocks: Technical specifications or commands
• Horizontal rules: Separate different goal categories

Writing Effective Goals

Strong sprint goals share common characteristics:

Outcome-Focused

Describe what users or the system can do after the sprint, not what tasks the team performs.

Good: "Users can authenticate with social media accounts" Weak: "Complete login feature tasks"

Measurable

Include criteria that make success objective.

Good: "Dashboard loads in under 2 seconds for 95% of users" Weak: "Improve performance"

Achievable

Goals should stretch the team but remain realistic for the sprint duration.

Good: "Complete user registration flow including email verification" Weak: "Build entire user management system"

Relevant

Goals should connect to product or project priorities.

Good: "Enable self-service password reset to reduce support tickets" Weak: "Refactor authentication code" (unless this connects to a larger objective)

Time-Bound

The sprint itself provides the time boundary. Goals should be completable within the iteration.

Goal Templates

Different teams use different goal formats. Here are common patterns:

Single Objective Format

By the end of this sprint, [user type] will be able to [action/capability].

Example: "By the end of this sprint, customers will be able to view their order history for the past 12 months."

Multiple Objectives Format

This sprint focuses on:
1. [Primary objective]
2. [Secondary objective]
3. [Stretch goal - if time permits]

Example:

This sprint focuses on:
1. Payment processing with Stripe integration
2. Receipt generation and email delivery
3. Stretch: Multi-currency support

Acceptance Criteria Format

Sprint succeeds when:
- [Criterion 1]
- [Criterion 2]
- [Criterion 3]

Example:

Sprint succeeds when:
- User can complete checkout without errors
- Order confirmation email arrives within 30 seconds
- Admin can view all orders in dashboard

Using Goals During the Sprint

Goals are not just for planning. Reference them throughout the iteration:

Daily standups: "How does today's work move us toward our goal?"

Scope decisions: When new requests arrive mid-sprint, evaluate against goals. "This doesn't help achieve our stated objectives—add to backlog for next sprint."

Blockers: When problems arise, prioritize resolution based on goal impact. "This bug blocks goal achievement—address immediately."

Sprint end: Review goals explicitly. "Did we achieve what we set out to do?"

Goals and Task Assignment

Sprint goals guide which tasks belong in the sprint:

1. Define the goal first
2. Identify tasks that contribute to achieving the goal
3. Add those tasks to the sprint
4. If tasks do not connect to goals, question whether they belong

Tasks without goal connection are not necessarily wrong, but they should be conscious decisions. Maintenance work, technical debt, and support tasks may be necessary even if they do not advance sprint goals.

Multiple Goals vs Single Goal

Some teams prefer a single, focused goal per sprint. Others define multiple objectives. Consider:

Single goal advantages:

• Maximum clarity and focus
• Easier to evaluate success/failure
• Prevents goal conflict

Multiple goal advantages:

• Reflects diverse work (features + bugs + maintenance)
• Allows partial success assessment
• More realistic for mixed workloads

Choose the approach that fits your team's work patterns and planning style.

Goal Evolution

Goals can change during a sprint, though this should be exceptional:

Valid reasons to modify goals:

• Critical business priority shift
• Discovery that original goal is impossible
• Major scope reduction accepted by stakeholders

Invalid reasons:

• Task took longer than expected
• Team wants to feel successful
• New idea seems more interesting

If goals change frequently, your planning process may need attention. Goals should be stable commitments, not aspirational wishes.

Permissions

Sprint goal editing requires edit_sprints permission. Typically:

• Agency Owners and Managers: Can edit goals
• Developers: Can view goals but may not edit
• Clients: View only if sprint access is granted

Check your workspace configuration if edit access seems incorrect.

Pro Tips

• Write goals before selecting tasks: Goals should drive task selection, not the reverse
• Post goals visibly: Consider sharing sprint goals in team channels or dashboards
• Review goals in retrospectives: "Did our goals accurately reflect what we should have achieved?"
• Keep goal count low: Three objectives maximum. More than that dilutes focus.

How to Report a Problem or Request a Feature

Your feedback matters. Here is how to share it:

If the goal editor needs additional formatting options or you have suggestions for goal management improvements, we want to hear them.

In the Sidebar, click on Support Tickets and open a ticket for the problem. Everything is interactive and fast through the GitScrum Studio platform.