ServiceNow Agile Development Best Practices

Maintain a Prioritized Product Backlog Aligned With Business Goals

An agile team is effective only when they are working on the highest-value items. ServiceNow’s work item tracking (epics, stories, and tasks) should reflect your business priorities: features that deliver customer value rank above nice-to-have enhancements, and critical bug fixes rank above non-critical issues. Your product owner or business lead should explicitly prioritize the backlog, not let priorities emerge implicitly. When team members ask what to work on next, the answer should be clear: work on the next item in the prioritized backlog. Without explicit prioritization, different team members may work on different things, and you lose the focus that makes agile development effective. Review and reprioritize your backlog regularly (weekly or at the start of each sprint) as new information arrives or business priorities shift.

Right-Size Stories So Your Team Can Complete Them in a Sprint

A story that takes longer than a sprint to complete creates uncertainty: the team cannot celebrate completion, the product owner cannot get feedback from users, and priorities may shift before the work finishes. Break large features into smaller stories that can be completed within a sprint, depending on your sprint length and team velocity. Stories should have clear acceptance criteria so the team knows what done means. Avoid stories that require work from multiple teams; instead, break dependencies so that a single squad or team can complete a story independently. When stories are too large, you will have many items marked in-progress at sprint end and little that actually shipped. When stories are too small, you create overhead in tracking and lose the sense of progress toward larger features.

Establish Sprint Ceremonies and Protect Team Focus

Agile ceremonies (sprint planning, daily standups, sprint reviews, retrospectives) create rhythm and communication discipline. Schedule sprint planning in proportion to sprint length, so a longer sprint gets a longer planning session. In planning, the team commits to specific stories they will complete in the sprint based on their historical velocity and capacity. Daily standups keep the team aligned on progress and surface blockers immediately. Sprint reviews demonstrate completed work to stakeholders and get feedback before the next sprint. Retrospectives allow the team to reflect on what worked and what to improve. Protect these ceremonies from interruption: cancel them only for genuine emergencies. When ceremonies are deprioritized, the team loses coordination and agile becomes chaotic.

Measure Team Velocity and Adjust Capacity Planning

Velocity is the amount of work (measured in story points) your team completes per sprint. Track your velocity over time to predict how much work your team can commit to in future sprints; the completed story points on each closed sprint give you that history. If your team has completed a similar number of story points in each recent sprint, that number is a reasonable starting point for the next commitment. If velocity is erratic, investigate whether planned capacity is changing (team members in training or other projects), whether stories are being mis-estimated, or whether unexpected interruptions are preventing the team from completing sprint work. Use velocity to communicate with business stakeholders about delivery timeline: dividing a feature’s estimated points by the team’s recent velocity gives a rough number of sprints, which is better treated as a range than a promise. This gives realistic expectations instead of promising delivery dates you cannot meet.

Manage Technical Debt Alongside Feature Development

Technical debt is code that works but is hard to maintain, poorly tested, or built on outdated patterns. Ignore technical debt and your team slows down over time as they struggle with complex code. Dedicate a portion of each sprint to technical debt: a meaningful portion of capacity goes to refactoring, adding tests, upgrading dependencies, or improving documentation. Create stories for technical debt items just as you do for features, and prioritize them based on impact: high-priority technical debt is code that blocks new features or causes frequent bugs. Review technical debt stories in sprint planning to ensure they get included; if every sprint prioritizes new features exclusively, technical debt accumulates until it becomes impossible to add new features efficiently. Communicate this trade-off to your business stakeholders: spending time on technical debt now reduces time-to-value for new features later.

Implement Continuous Integration and Automated Testing in Sprints

Code quality slips when testing is deferred until the end of a sprint or the end of a release. Instead, build testing into daily work: developers write unit tests as they write code, and automated integration tests run frequently (daily or on every code commit). Use test results in your sprint metrics: if test coverage is dropping or defect escape rate is rising, the sprint is not as healthy as story completion suggests. Require code reviews before merging so that knowledge is shared and quality is maintained. Automate deployment so that code that passes automated tests can be deployed to production quickly, reducing the lag between completing work and getting user feedback. This integration of quality into the development process prevents quality from becoming an afterthought.

Writing acceptance criteria a tester can run without the author

Acceptance criteria often fail in a predictable way. The author writes them from memory of the discussion, a tester reads them cold, and the two readings diverge at the first edge case. The practical test is simple: could someone who was not in the refinement session pick up the story and decide, without asking, whether it passes. If the answer lives in a meeting that never reached the item, the criteria are not finished, however tidy they look. A fuller list of checks to draw from is in the testing and acceptance checklist.

Write each criterion as an observable outcome in the platform, such as a record being created with a given field value or a notification reaching a named group. Avoid criteria that describe effort, like ensuring the form is intuitive, because nobody can mark that as met. Where a story touches a rule that already exists, name the rule in the criterion so the tester knows which behavior to check for regression. Teams that want outside eyes on test coverage often pair this with quality assurance testing support.

Giving unplanned support work a place on the board

Every team that delivers a product also answers questions, fixes small defects and handles operational requests, and that work rarely appears in the sprint plan. When it has no place of its own, it is absorbed into the sprint quietly, and the committed scope fails for reasons that look like estimation errors. A better practice is to make the interruption visible. Give support work a separate lane or a fixed allocation that the sprint plan reserves explicitly, and record its items so the team can see the actual load.

The choice of allocation is a judgment for the team and its product owner. The roles guide sets out who is involved in those decisions. What matters is that the decision is written down and reviewed, so that a rising support load shows up as a planning question rather than as a sequence of missed commitments.

Turning retrospective actions into backlog items with owners

A retrospective that ends with a list of improvements and no owners is a common source of cynicism. Each agreed action should become a backlog item with a named owner, a stated outcome and a place in the next planning cycle. An action that cannot be written as a backlog item is probably too vague to act on, and the team should sharpen it before the meeting closes.

Review open retrospective items at the start of each planning session. Close those that were completed, drop those the team has decided against, and carry forward only those with a current owner. Over several cycles the list becomes a readable record of what the team changed and what it chose to leave alone.

Handling cross-team dependencies without stalling the sprint

A story that needs another team to change something first will sit in progress until that team responds, and the sprint report will show it as the team’s failure. The practice that helps is to make the dependency an explicit item with its own owner in the other team, and to decide during planning whether the story is committed only if the dependency is resolved. Stories committed on that condition should be marked as conditional on the board, not hidden in the normal count.

A sprint goal that survives a bad week

A sprint goal is most useful in the week when the plan falls apart. A single sentence describing the outcome the team is working toward gives everyone a basis for choosing between two pieces of work when time runs short. Write the goal during planning, record it on the sprint, and read it at the daily check-in. When the goal is no longer reachable, say so early and agree a revised one with the product owner, rather than carrying a goal everyone has stopped believing in.

Questions teams ask about these practices

How much detail belongs in acceptance criteria for a small change?

Enough for a tester to verify the change without interpreting intent. A one-field change may need two or three criteria. What it does not need is a paragraph restating the background, which tends to hide the one condition that matters.

Should a support lane be part of the sprint at all?

Often it is better to show it on the same board as a separate lane than to pull it out completely. Keeping it visible lets leaders see the trade-off between features and interruptions in one place.

What if the product owner keeps changing the sprint goal?

Treat each change as a decision that costs something. Record the change, the reason and what was dropped to accommodate it. After a few cycles the pattern is usually clear enough to take to a governance forum, as it is a question about priority rather than about the team’s execution.

Are these practices useful for a team that has just started?

They are most useful at the start, before habits harden. A new team that writes observable criteria, names its support load and keeps a short list of owned actions avoids much of the early confusion that gets blamed on the tool.

Next step

An outside reviewer of the board and the planning routine often spots friction the team has stopped noticing.

Agile Development in ServiceNow: table names and field values to know

ServiceNow Agile Development tracks work as epics, stories and story tasks, with stories grouped into sprints and sized in story points. A team’s velocity is the sum of points on stories completed in a sprint, so consistent point estimates matter more than any dashboard setting.

The names below are common out-of-box values. Check them on your own instance and release, because labels, states and roles differ between releases and plugin versions.

Example (hypothetical): a squad closes a sprint with one story still at the testing stage. Rather than counting the points as done, the product owner moves the story to the next sprint and notes why. The velocity figure stays honest, and the next planning session starts from what was actually finished.

Should unfinished stories keep their points when they move to the next sprint?

Most teams count points only when a story reaches its completed state, so a carried story adds nothing to the closing sprint. Some re-estimate the remaining work before carrying it over. Pick one rule and apply it every sprint, or velocity stops meaning anything.

Which table do I report on for sprint scope?

Report on the story table, filtered by the sprint reference, and sum the story points field. Reporting on tasks measures effort on pieces of work, not delivered value, which is a different question and rarely matches what stakeholders asked.

Does the product owner need a specific role?

Agile Development has its own scrum-related roles on many releases. Role names and what each can change vary by release, so compare them against your instance before granting anything beyond what a person needs.

For wider planning context, see demand management practices, the portfolio management guide and SPM implementation support.