ServiceNow Agile Development Requirements Workshop Questions

This page lists the workshop questions a team should answer before running agile development on ServiceNow. The questions cover team structure, sprint and ceremony design, backlog prioritisation, the definition of done, dependencies, and how agile links to release and governance.

Agile Development Practice as a Strategic Choice

Agile Development on ServiceNow supports teams using Scrum, Kanban, or hybrid agile methodologies to plan and execute software development. Unlike waterfall or traditional project management, agile emphasizes iterative development, regular team collaboration, and responding to change. The workshop questions for agile development focus on team structure, sprint practices, backlog management, dependency handling, and integration with broader release and governance processes. The decisions made determine whether agile accelerates delivery or becomes a process burden.

Team Structure and Ceremony Definitions

The first set of questions focuses on how teams are organized and how agile ceremonies work. Will teams be organised by product, by component, or by cross-functional feature? Will you use two-week sprints, one-week sprints, or continuous flow? Will sprint planning happen at the start of each sprint or continuously? Will stand-ups be daily, or less frequently? How long will sprints be allowed to last before retrospectives enforce changes?

Team organisation affects communication and dependencies. A product team (all engineers for a single product) has clear ownership and can make decisions independently. A component team (database engineers, UI engineers, integration engineers) has deep expertise but requires coordination across teams. The best team structure depends on your codebase, product strategy, and how frequently teams need to interact.

Ceremony definitions determine whether agile adds value or becomes overhead. A two-week sprint with ninety-minute planning and daily stand-ups A planning session every two weeks plus a short daily stand-up takes a modest slice of each person’s week, and the total grows quickly when those meetings run long.. A four-person team loses over a week of productivity every month to ceremonies. For very small teams, longer sprints or lighter ceremonies may be more appropriate. For large programs, more structure may be necessary to coordinate dependencies.

A related question is how agile teams interact with non-agile teams. Do QA teams work on the same sprint cycles? Do operations teams engage in sprints? Do security teams have sprint participation, or do they review deliverables after each sprint? Clear integration rules prevent agile teams from becoming isolated.

The warning sign is ceremony bloat. If retrospectives identify that too much time is spent in meetings, trim ceremonies. Drop stand-ups to three times per week. Extend sprint length. Use asynchronous updates instead of all-hands ceremonies. Agile should enable delivery, not slow it down with process.

Backlog Management and Prioritization

Questions about backlog focus on how work is captured, prioritized, and moved through the team. Will all work be captured in the backlog, or only feature development? Will operations issues, technical debt, and bug fixes also be backlog items? Who prioritizes the backlog? Does product management own prioritization, or is it collaborative with engineering? What criteria are used to prioritise items?

Backlog management determines what actually gets done. If only features are in the backlog and operations work is handled separately, teams may over-commit to features while critical infrastructure work goes undone. If the backlog includes everything, teams need clear rules about how much time goes to features versus operations. A common approach is most to features, a portion to operations and support, a portion to technical debt.

Another backlog question is size and estimation. How detailed are backlog items? Can developers start work from a backlog item alone, or do they need additional specification? Is estimation required? If estimated, who estimates and how confident is the estimation? Story point estimation helps predict capacity and plan sprints, but poor estimation wastes time and creates false commitments.

A related question is managing dependencies across teams. If team A’s backlog depends on team B completing their work first, how is that managed? Will teams pull dependencies into their sprints, or will dependency items get pushed to downstream teams? Clear dependency management prevents bottlenecks and reduces waiting time.

The warning sign is a massive, undifferentiated backlog. If the backlog grows large and no one knows what is actually needed, prioritization becomes arbitrary and teams do not know what matters. Keep the backlog focused on the next few sprints in detail. Items beyond that can be rough sketches. Regularly groom the backlog to remove items that no longer matter and refine items coming due.

Sprint Execution and Definition of Done

Questions about execution focus on how teams actually work during sprints and what “done” means. Will teams commit to sprint goals at the start of each sprint, or will they work from a pull-based backlog? What are the criteria for moving an item to “done”? Does done mean code complete, tested, or deployed? Do all items need to meet the same definition of done?

Definition of Done is critical to agile quality. If items can be marked done without testing, quality degrades and technical debt accumulates. A typical definition of done might be: code complete, peer review passed, unit tests passed, integration tests passed, product owner approved. Stricter definitions ensure quality but slow down work. Looser definitions accelerate velocity but reduce quality. The definition should be explicit and non-negotiable.

Another execution question is handling mid-sprint interruptions. What happens if a critical issue emerges? Can a team pull items out of a sprint to address urgencies, or does the sprint stay locked? Flexibility to handle emergencies is necessary. Excessive mid-sprint changes prevent sprints from completing as planned. A rule might be: interruptions are allowed only with product owner permission and only if lower-priority sprint items are removed.

A related question is partial completion. If a sprint ends and an item is nearly complete complete, does it count as done? Most teams do not count partial work. Incomplete items are moved to the next sprint. This forces teams to size items small enough to complete in a sprint.

The warning sign is sprints that slip into subsequent weeks. If sprints consistently overrun by a few days, either items are too large, estimates are wrong, or the team is under-resourced. Investigate and adjust. Consistent sprint overruns indicate the team is committing to more than they can deliver.

Release Planning and Governance Integration

Agile teams deliver working software regularly, but organizations still need release planning and governance. Questions about release planning focus on how agile sprints align with release schedules. Will every sprint produce a release? Will sprints feed into a quarterly release train? Will teams hotfix production issues outside of sprints?

A common approach is: teams deliver working software every sprint, but releases to production happen less frequently (quarterly, monthly, or event-driven). Between sprints and releases, features accumulate in staging environments. Separate release calendars allow teams to move fast in development while managing production risk carefully.

Another governance question is change control and approval. Do all changes need approval before deployment? Does approval speed up or slow down agile delivery? Some organizations use lightweight approval for low-risk changes (documentation updates, minor bug fixes) and full approval for high-risk changes (database changes, security updates). This balances agility with governance.

A related question is rollback and incident management. If a release causes incidents, who decides to rollback? How long does rollback take? Faster rollback decisions let teams recover quickly from failed releases. Slow rollback processes make teams risk-averse and slow down deployment.

The warning sign is agile teams blocked by release management governance. If agile teams develop features every sprint but releases happen quarterly, agile delivers no business value until release day. If release approvals take weeks, teams lose momentum. Align release processes with agile delivery. At minimum, teams should be able to release monthly or on-demand for high-value features.

Metrics and Continuous Improvement

The final set of questions focuses on what metrics teams will track and how they will improve. Will you track velocity (features delivered per sprint)? Cycle time (time from idea to delivery)? Quality (defects per release)? Customer satisfaction? Team health (morale, turnover)? Each metric should serve a purpose: either help teams plan better or identify improvements.

Velocity tracking helps teams predict capacity and plan realistic sprints. If velocity is fourteen story points per sprint consistently, teams can commit to features totalling fourteen points and deliver on time. Velocity should stabilise after a few sprints. If velocity varies wildly, either estimation is inconsistent or interruptions are disrupting sprints.

Cycle time tracking helps identify bottlenecks. If cycle time from idea to production is six months but sprints are two weeks, where is the delay? Is it in code review? QA? Deployment pipeline? Release windows? Identifying the bottleneck allows targeted improvement.

Quality metrics (defect rates, escaped defects, customer-reported issues) show whether speed is being sacrificed for quality. Some defects are acceptable; zero defects is impossible. The rule is: quality should be explicit and measured, not assumed.

Retrospectives are the mechanism for improvement. Every sprint should end with a brief retrospective where teams discuss what went well, what could improve, and what to try next sprint. Act on retrospective feedback. If teams always discuss the same problem but never address it, retrospectives become pointless and engagement drops.

The warning sign is teams obsessed with velocity at the expense of delivery and quality. Velocity is useful for planning, not for performance evaluation. High velocity with frequent incidents and rework is not success. Focus on sustainable, predictable delivery that maintains quality and team health.