Troubleshooting ServiceNow Agile Development: A Practical Guide

This page helps ServiceNow Agile teams work through sprint problems by symptom. Each section names a symptom, a likely cause and the checks to run, covering the sprint backlog, the board, velocity, planning effort, sprint goals, dependencies, workflow states and team capacity.

Symptom: User Stories Are Not Appearing in the Sprint Backlog

If user stories are created but do not appear in the sprint backlog, check the backlog view configuration. Verify that the sprint backlog view is filtering correctly: it should show stories assigned to the current sprint. Check that stories are actually assigned to a sprint: stories without a sprint assignment will not appear in any sprint backlog. Look at the story status: some backlog configurations filter by status (e.g., only show stories with status New or In Progress, not Closed). If stories are assigned to a sprint but not showing, check whether the sprint backlog view has visibility restrictions (only shows stories for certain teams or projects). Test by creating a test story, assigning it to the current sprint, and verifying it appears in the backlog. If it does not appear, drill into the view configuration and check filtering logic.

Symptom: Sprint Board Is Not Updating in Real-Time

If the sprint board shows stale data (a story shows In Progress but the developer marked it Done, or vice versa), the board may not be refreshing. Check whether the board is using real-time updates or periodic refresh. If periodic, how often does it refresh? If a story status was updated but the board has not refreshed yet, wait for the refresh interval. If the board never updates, check whether JavaScript is enabled and whether the board view has permission to access stories (permission errors may prevent updates). Test by creating a test story and manually changing its status; observe how long the board takes to reflect the change. If it never updates, there may be a view configuration error or permission issue requiring investigation.

Symptom: Sprint Velocity Is Incorrect or Not Calculating

Sprint velocity measures how much work a team completed (typically measured in story points or tasks). If velocity is not calculating, verify that stories are being marked complete at the end of the sprint. Stories must transition to Done status to be counted. Check whether the velocity calculation includes only Done stories or all stories in the sprint (some teams count In Progress as partial credit). If velocity is very high or very low compared to prior sprints, check data quality: did the team actually estimate the work (assign story points), or are stories missing estimates? Stories without estimates will not be counted in velocity. Check whether the velocity report is looking at the correct sprint and correct team; misconfiguration can produce wrong totals.

Symptom: Sprint Planning Takes Too Long or Requires Manual Data Entry

Sprint planning (selecting stories for the next sprint) should be efficient if backlog is organized and stories are well-estimated. If planning is tedious, check whether the backlog is prioritized. If the backlog is disorganized, teams spend meeting time discussing priority instead of selecting stories. Check whether stories have estimates. If not, estimation happens during planning, making planning longer. Automate story selection if possible: if the team has consistent velocity and stories are ordered by priority, select top stories until velocity capacity is reached. Check whether the sprint planning workflow can automate moving stories from backlog to sprint, rather than requiring manual moves.

Symptom: Sprint Goals Are Not Being Tracked or Communicated

Sprint goals describe what the team intends to accomplish (e.g., “deliver search functionality, fix high-priority bugs, reduce technical debt”). If goals are not tracked, check whether the sprint record has a goals field and whether teams are filling it out. If goals exist but are not visible, check whether dashboards and reports are surfacing them. Goals should be visible to stakeholders so they understand sprint intent. If goals are documented but not being enforced (a team says the goal is search functionality but spends the sprint on other work), that is a discipline issue, not a configuration issue; management oversight is needed.

Symptom: Dependencies Between Stories Are Not Being Managed

If stories have dependencies (Story A cannot start until Story B is done) but the system is not tracking them, check the dependency configuration. Verify that the story record has a dependency field and that teams are recording dependencies when they exist. Check whether dependency visualization is available: dashboards should show which stories are blocking others. If dependencies are not being tracked, team capacity may be wasted (a team works on Story A when it is blocked, instead of working on Story C which is ready). Implement dependency tracking and review dependencies during sprint planning to ensure the team is working on stories that are not blocked.

Symptom: Agile Board Shows Workflow States That Do Not Match Team Definition

If the board shows columns (e.g., New, In Progress, In Review, Done) that do not match how the team works, the board workflow is misconfigured. Check the workflow state machine for the story record. Verify that states match the team’s process: Do stories need review before Done? Do they need QA? The board should reflect the actual workflow. If the workflow has more states than the board displays, some states may be hidden. Check board configuration to ensure all workflow states are shown as columns. Test the workflow by moving a test story through all states and observing whether the board reflects state changes correctly.

Symptom: Team Capacity Planning Is Not Preventing Over-Allocation

If a team is allocated more work than they have capacity for (100 story points in a sprint when the team’s velocity is 80), the system is not enforcing capacity constraints. Check the sprint planning configuration: is there a validation rule that prevents adding stories beyond team capacity? If not, one should be configured. During sprint planning, calculate remaining capacity and warn when adding stories would exceed capacity. However, validation alone is not sufficient: team leadership must also enforce discipline (do not override the warning without agreement). Capacity management is both technical (system configuration) and cultural (team discipline).

Symptom: Release Planning Does Not Track Story Progress Across Sprints

If a release spans multiple sprints (many features need to be completed across three sprints for a release), release planning should track progress: which sprints are committed to the release, how many stories are targeted per sprint, and what is total progress. Check whether releases are configured and stories are assigned to releases. Check whether release burndown charts (or equivalent progress tracking) are updating as sprints complete. If release tracking is not working, either releases are not configured, or stories are not assigned to releases correctly. Verify release configuration and story-release assignments.

Choosing who to call first when a symptom appears

Agile tool problems reach the wrong person surprisingly often. A developer sees a missing notification and assumes the platform is broken, when the real cause is a group that was never assigned to the team. A product owner sees duplicate stories and asks the integration engineer to fix the sync, when the duplicates were created by a manual import that nobody recorded. A first triage step that sorts symptoms by their likely owner saves more time than any single technical fix, because it stops the investigation from going round in circles.

A diagnostic habit that prevents many loops

Many troubleshooting loops begin with a change that nobody wrote down. Before opening an investigation, reconstruct what changed in the past few days: configuration updates, new group memberships, imports, integration credentials and any manual clean-up. Ask the team to check their own change record first. The answer is often there, and it is far quicker than a technical search through logs.

1. Write the symptom in one sentence, with the user, the record and the time it was seen.
2. Reproduce it with a test user in the same group, and note whether it happens for everyone or only for some people.
3. List the changes from the last few days and mark which ones touch the affected records.
4. Test the most likely cause first, and change one thing at a time so that the result can be trusted.
5. Write the cause and the remedy into the team’s change record, and add a line to the runbook if the symptom is likely to recur.

Signs the problem is not configuration at all

Some symptoms look like tool faults but come from how the team works. A story that keeps returning to the backlog may be an item that nobody has the authority to accept, so it is correctly sitting in review. A sprint that seems to hold far too much work may reflect a team that adds items without removing any. These are process issues, and a configuration change will only hide them. When a symptom returns after a fix, ask whether the team’s working agreement has changed before reopening the technical investigation.

When to stop investigating and roll back

If a symptom affects active delivery and the cause is not clear after a reasonable check, reverting the most recent change is often the quickest safe step. Set that threshold in advance with the platform owner, so that the team does not spend a sprint trying to diagnose a fault that a rollback would clear. Leave the rolled-back change on record, noting why it was reverted, so a corrected version can go in later.

Keeping a small runbook that people will use

A runbook for the agile tool works best when it is short. Include the symptom families above, the first check for each, the usual owner and the escalation trigger. Add a link to the change record for each entry so that the runbook points to evidence rather than to memory. Review the runbook at the end of each cycle, and delete entries that have not been used, since a long runbook is a document nobody opens during an incident.

Why do notifications stop after a team reorganisation?

Often because the group membership changed and the notification rules still point at the old group. Check the group first, then the rule that sends the notification, and confirm the recipient’s own preferences. Testing with a user from each affected group takes less time than a broad investigation.

How do we stop duplicate stories from a manual import?

Run imports from a staging copy with a reconciliation step that compares titles and source references before the load. Make the owner of the import responsible for checking the result, and do not allow an import to run against the live backlog without a recorded approval.

Is it safe to ask a user to clear their browser cache when the board looks wrong?

It can help with display issues, but it should not be the first step. If the board shows stale data for everyone, the cache is not the cause. Test with a fresh session in a private window, which tells you whether the problem follows the user or the record.

When should a symptom go to the platform vendor or partner?

When the reproduction is clear, the affected records are known and the internal checks have ruled out your own changes. Bring the reproduction steps, the affected users, the time of first occurrence and the change record. A vague report often comes back with a request for exactly that information.

The fastest route is often a short review of the last few changes, not a rebuild.

For a broader view of how issues are handled in a live platform, see the integration error handling guide and the major incident communication guide.