Data model enhancements from Agile Development 1.0 to Agile Development 2.0

  • Release version: Xanadu
  • Updated October 23, 2025
  • 3 minutes to read
  • Summarize
    Summarized using AI
    This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.

    Summary of Data Model Enhancements from Agile Development 1.0 to Agile Development 2.0

    Agile Development 2.0 introduces significant data model enhancements compared to Agile Development 1.0, streamlining the management of agile teams and sprints. Notably, Agile Development 1.0 features like the Sprint burndown chart are deprecated, marking a transition to a more integrated approach for Agile methodologies.

    Show full answer Show less

    Key Features

    • Assignment Group Standardization: Agile Development 2.0 utilizes a common construct, the Assignment Group, to represent agile teams. This replaces the standalone Release Team entity from Agile Development 1.0, allowing for better reporting and management across all platform tasks.
    • Independence of Groups from Releases: Teams no longer need to be created for each release. In Agile Development 2.0, groups can be established independently, allowing teams to work across multiple releases without redundancy.
    • Sprint Creation Flexibility: Agile Development 2.0 allows for the creation of sprints without requiring a release to be defined first. This flexibility supports better agile execution and backlog management.
    • Ongoing Team Backlogs: Teams can maintain a continuous backlog independent of specific releases, facilitating ongoing project management and story execution.
    • Release and Group Association: The introduction of the m2mreleasegrouplist table supports the association of groups with releases without mandating group creation for each release. This helps in calculating team capacity for releases.

    Key Outcomes

    With these enhancements, ServiceNow customers can expect improved efficiency in managing agile teams, greater flexibility in sprint management, and enhanced capacity planning for releases. The shift to using Assignment Groups as a consistent method across the platform allows for streamlined reporting and resource allocation, ultimately leading to more effective agile practices within their organizations.

    Agile Development 2.0 offers a few data model enhancements over Agile Development 1.0.

    Important:
    Agile Development 1.0 and its features such as Sprint burndown chart and release burndown chart are deprecated and no longer available. Agile Development 2.0 provides the latest experience for supporting your Agile work methodology.

    Use of the common platform construct — Assignment Group

    To map an agile team (scrum team), Agile Development 1.0 uses a separate entity called the Release Team table ( scrum_pp_team). This entity is associated to a release entity as displayed in the following screen shot.

    Figure 1. Scrum release
    Teams within a release

    All other tasks on platform such as incidents, problems, changes, projects rely on the assignment group entity to make assignments to a group. Group managers can run reports on an assignment group to gain insight into the work assigned to their groups.

    To standardize the use of a group across platform even for scrum work such as stories and tasks, the standard construct Assignment Group is used as opposed to the standalone entity Release Team. Agile Development 2.0 uses assignment groups to map agile teams. An assignment group of type Agile Team is used for defining an agile team.

    Figure 2. Groups
    Use of Assignment Groups in Agile Development 2.0

    Agile team (group) need not be created for each release

    With Agile Development 1.0, teams are to be created for each release and the teams are to be associated to each release. For example, if a scrum team called Team — Alpha works on multiple quarterly releases. You cannot create the team for one time and associate the team to any release, or release over release. Each time a new release is created, you must create a team with the same name and associate team to the release.

    With Agile Development 2.0, groups are created independent of releases, and you can work on stories from multiple releases without recreating the group for every release.
    Figure 3. Scrum release
    Teams within a release Same team is created four times, one for each release

    Sprints can be created without a release

    With Agile Development 1.0, creating a release is mandatory for creating sprints. Sprints cannot be created for a team independently. Agile Development 1.0 mandates the creation of a release for story execution via sprints. If there is no release, sprint cannot be populated on a story record.
    Figure 4. Sprints
    Sprints created in the context of a release
    In Agile Development 2.0, sprints are associated with Assignment Groups. Sprints are associated with Assignment Groups

    Team backlog can be maintained independent of release

    Typically, a team can have an ongoing team backlog release after release, it can pull stories from its backlog, and execute them through sprints in the release.

    With Agile Development 1.0, a team cannot be defined without defining a release. Hence, team backlog cannot be maintained independent of a release.

    With Agile Development 2.0, an assignment group is not created within a release. It can be associated to the release, but not created within a release. Hence, an assignment group can maintain its own backlog.

    Figure 5. Group backlog with Agile Development 2.0
    Group backlog with Agile Development 2.0

    Association between Release and Group

    As there is no direct relation between a release and a group in Agile Development 2.0 (groups are independent and do not have to create groups for each release), the m2m_release_group_list table has been introduced. This table stores the association of a group with a release. This association is not used for sprint generation, but is used to derive the capacity of a release.
    Specify the number of sprints for which the group works in a release. From the capacity of the team, the capacity of the release is derived.
    Table 1. m2m_release_group
    Team Start Sprint End Sprint Points (each sprint) Total Group Capacity For Release
    A A_Sprint 1 A_Sprint 3 30 90 (3*30)
    B B_Sprint 1 B_Sprint 4 40 160 (4*40)
    Total Release Capacity = 90+ 160 = 250 points
    Release — Group association in Agile Development 2.0