ServiceNow Agile Development: Roles, Responsibilities and RACI

Agile Team Structure and Role Definitions

Agile development in ServiceNow involves three core roles: Product Owner (defines requirements, prioritises backlog, accepts work), Scrum Master (removes obstacles, facilitates ceremonies, protects team), and Development Team (builds the product, self-organises, delivers incrementally). Stakeholders (executives, customers, users) provide input but do not direct the team’s work.

Define role boundaries: the Product Owner owns what is built; the Scrum Master owns how it is built (process); the Development Team owns the quality of work. This separation prevents scope creep and allows the team to maintain sustainable pace.

RACI Matrix for Agile Delivery

Product Owner Accountability

The Product Owner is accountable for product success: are we building the right thing, in the right order? They own the product backlog (creation, prioritisation, refinement) and they accept completed work. They are the single voice of the customer and stakeholders to the team.

Key decisions owned by the Product Owner: what features are in the product, which backlog items are prioritised, what is the definition of done for an item, whether an item meets acceptance criteria, and when to release.

Scrum Master as Facilitator and Coach

The Scrum Master does not manage the team; they facilitate the team’s self-organisation and coach the team on Agile practices. They protect the team from external interruptions during sprints and help the team improve their process.

Key responsibilities: facilitate sprint ceremonies (planning, standup, review, retrospective), help the team identify and remove blockers, coach the team on Agile practices, and ensure visibility to stakeholders without disrupting the team’s focus.

Development Team Ownership of Delivery

The Development Team owns how they deliver the work. They self-organise, decide how to split tasks within a sprint, support each other to meet sprint goals, and ensure quality before marking work as done. The team is cross-functional: includes developers, testers, and specialists needed to deliver a potentially shippable product increment.

Key responsibilities: estimate story effort, commit to a sprint plan, deliver on that commitment, maintain code quality, and improve the team’s velocity over time.

Sprint Cadence and Ceremonies

Choose a fixed sprint cadence and keep it steady. Each sprint includes: Sprint Planning (what will we build this sprint?), Daily Standup (how are we progressing?), Sprint Review (do we have a potentially shippable increment?), and Sprint Retrospective (how can we improve?). Keep ceremonies short and sized to the sprint length.

Backlog Management and Capacity Planning

The Product Owner maintains the product backlog: a prioritised list of features, enhancements, and bug fixes. Before each sprint, the team forecasts how much capacity they have (based on velocity and planned absences) and commits to backlog items that fit in that capacity.

Velocity is a measure of the team’s capacity: how many story points can they complete per sprint? Track velocity over time. As the team stabilises, velocity becomes predictable, making it easier to plan releases.

Stakeholder Engagement and Communication

Stakeholders have input but do not direct the team. The Product Owner gathers stakeholder feedback and prioritises accordingly, but shields the team from constant re-prioritisation and scope changes. Sprint reviews invite stakeholders to see progress; retrospectives are team-only.

Communication cadence: status updates to stakeholders monthly or quarterly, sprint demos for interested stakeholders every sprint, and detailed metrics (velocity, burn-down, backlog size) in a dashboard available to anyone.

Scaling Agile for Large Teams or Programs

If you have multiple Agile teams working on the same product, you need coordination: shared definition of done, shared architectural standards, regular synchronisation between teams (scaled events like program increment planning), and a program-level backlog.

Avoid creating a layer of traditional project management on top of Agile; instead, use Agile at program level: program increment planning, demo, and retrospective that span all teams.

Settling decision rights before the first sprint starts

A RACI grid answers who does what in general terms. What teams actually argue about is narrower: who may move a story out of an active sprint, who may change the order of the backlog mid-cycle, and who has the final say when a developer and a product owner disagree about whether something is finished. Write those three decisions down with one named owner each before the first sprint begins. An unnamed owner is often a senior stakeholder who appears at the review and overrules the team, and that pattern is hard to undo once it has started. Read the agile governance model guide alongside this section, since it covers the forum where those owners get confirmed.

It helps to separate deciding from consulting. A product owner may set the sprint goal after listening to the team, and the team’s estimate may change the scope without changing the goal. The decision table below records that difference, so that anyone reading a request can tell whether it is a question or an instruction.

A decision-rights table for the cases that cause friction

Setting up the role assignments in the platform

Roles in the tool only do useful work when people are assigned to them on purpose. The order below avoids the situation where a person holds the rights of a product owner but still works like a stakeholder who sends requests from the corridor.

1. Check the role list against the decision table above. If a decision has no role behind it, either create one or assign it to the nearest owner and say so in writing.
2. Assign one primary owner per team for each role. A second person can hold the role as backup, but the backup should be named and should not act without the primary knowing. Group membership is often the cleanest way to hold these assignments, which is why the group concept explained guide is a useful reference before you start.
3. Check whether the product owner also has a say in how developers are assessed. When one person sets the order of work and influences who is rewarded for it, the backlog tends to bend toward individual interests rather than the team’s priorities.
4. Test the assignments with a throwaway story. Move it through each state as each role, and confirm that the system allows exactly the moves the table permits and no others.
5. Record the assignments in the team charter, and review them whenever someone changes jobs or leaves the team.

Where strict role separation breaks down

A small team rarely needs three separate roles in practice. A team that size can let one person carry both scrum master and product owner duties, provided they are honest about which hat they are wearing in a given meeting. The risk is not the combination itself. The risk is the unrecorded switch, where a decision made as product owner is later defended as a process point. Write the combined role into the charter, and ask the person to name the role they are using whenever they make a call that changes scope.

Contractors and shared-service staff create the opposite problem. They often hold a developer role while taking direction from a steering group, and that split is easy to miss on a grid. Name the person who gives them direction, even if the platform role says something different.

Signs the roles are working

• Scope changes arrive with a recorded reason and a named decision owner.
• Developers can say who to ask about a priority question without raising it in the room.
• Stakeholders attend reviews to see progress, and their requests appear in the backlog rather than in side conversations.
• Retrospectives produce changes to the process, not complaints about individuals.

When to revisit the role model

Look at the role model again after any change of product owner, after the team grows past the size it was designed for, and whenever a decision in the table is disputed twice in one quarter. A second dispute often means the row was written from a template rather than from how the team actually makes that call. Usually the repair is a sharper description of who decides and who only advises, rather than an extra role.

Who owns the sprint goal when the product owner is away?

The goal does not lapse with the product owner. Name a delegate who may make scope decisions for the duration of the absence, record that delegation in the charter, and make sure the delegate can say no to a mid-sprint request without escalating it to the sponsor.

Can a stakeholder remove a story from a sprint?

A stakeholder can ask. Removing a committed story is a scrum master decision in many setups, taken after the product owner agrees the reason. If stakeholders can change sprint content directly, the team loses the ability to forecast, and the velocity figures stop meaning anything.

Is the scrum master the team’s line manager?

Not in a healthy setup. The scrum master facilitates and removes obstacles, and a line manager sets performance expectations. When both sit in one person, team members tend to hold back blockers they fear will be judged. Where the same person has to do both, keep the two conversations visibly separate.

What happens when a developer does not agree that work is done?

The definition of done is the tiebreaker, not the seniority of the people in the room. If the definition is clear, the disagreement is about a fact that can be checked. If the definition is vague, the dispute goes to the product owner, and the team should then tighten the wording in the next retrospective.