--- sourceDocument: Zurich Strategic Portfolio Management sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/it-business-management Release : - zurich ft:locale : - en-US ft:publication_title : - Zurich Strategic Portfolio Management ft:clusterId : - itbm bundleId : - itbm workflow : - Technology --- # Data model enhancements from Agile Development 1.0 to Agile Development 2.0 # Data model enhancements from Agile Development 1.0 to Agile Development 2.0 {#ariaid-title1} * Release version: Zurich * * Updated March 12, 2026 * * ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 3 minutes to read Summarize ![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) 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 improvements over Agile Development 1.0, aligning better with the ServiceNow platform's common constructs and enhancing flexibility in managing agile teams, releases, sprints, and backlogs. Agile Development 1.0 features, including Sprint and Release burndown charts, are deprecated in favor of the updated Agile Development 2.0 experience. Show full answer Show less ## Key Enhancements * **Use of Assignment Group Instead of Release Team:** Agile Development 1.0 used a separate Release Team table to represent scrum teams, tied strictly to releases. Agile Development 2.0 replaces this with the platform-standard **Assignment Group** entity of type "Agile Team" to represent agile teams, enabling consistency across platform modules like Incidents, Problems, Changes, and Projects. * **Teams Independent of Releases:** Unlike Agile Development 1.0, where teams had to be created for each release, Agile Development 2.0 allows teams (assignment groups) to exist independently of releases. This enables teams to work across multiple releases without needing to recreate or associate new teams for each release. * **Sprints Creation Without Releases:** Agile Development 1.0 required a release to be created before sprints could be established. Agile Development 2.0 decouples sprints from releases by associating sprints directly with assignment groups, allowing for more flexible sprint management. * **Independent Team Backlogs:** Teams can maintain ongoing backlogs independent of specific releases. Agile Development 2.0 supports teams managing their own backlog continuously, pulling stories into sprints across multiple releases, unlike Agile Development 1.0 where backlogs were release-bound. * **Release and Group Association via a Link Table:** Since groups no longer depend on releases, Agile Development 2.0 uses the **m2mreleasegrouplist** table to associate groups with releases for capacity planning. This many-to-many relationship enables calculation of release capacity based on the number of sprints a group works on and the points per sprint. ## Practical Benefits for ServiceNow Customers * **Standardized Team Management:** Leveraging the platform's Assignment Group simplifies integration and reporting across ITSM and Agile processes, enabling group managers to monitor work assignments comprehensively. * **Improved Flexibility:** Teams and sprints can be managed independently from releases, supporting more dynamic and continuous agile workflows, which better fit real-world agile practices. * **Enhanced Capacity Planning:** The new association table allows precise calculation of release capacity based on team involvement, improving resource planning and forecasting. * **Streamlined Agile Data Model:** By deprecating the Release Team entity and tightly integrating with core platform constructs, Agile Development 2.0 reduces complexity and maintenance effort. Agile Development 2.0 offers a few data model enhancements over Agile Development 1.0. ## Use of the common platform construct --- Assignment Group {#data-model-enhancements__section_uqp_4qr_3gb} 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. 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](https://www.servicenow.com/docs/X6EY50mJINfKaRnIpX3w3A "ServiceNow Agile Development 2.0 provides an agile software development environment for product-based or project-based efforts, using the Scrum framework. Implement a pure agile approach over the entire life cycle of a product, or a hybrid approach using agile methods within a traditional project structure.") provides the latest experience for supporting your Agile work methodology. 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. ## Agile team (group) need not be created for each release {#data-model-enhancements__section_x4p_hrr_3gb} 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. ## Sprints can be created without a release {#data-model-enhancements__section_pj4_rrr_3gb} 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.In Agile Development 2.0, sprints are associated with Assignment Groups. ## Team backlog can be maintained independent of release {#data-model-enhancements__section_el1_1sr_3gb} 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. ## Association between Release and Group {#data-model-enhancements__section_hnr_3sr_3gb} 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.{#data-model-enhancements__table_ndx_lsr_3gb__entry__5} | 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) | [Table 1. m2m_release_group] {#data-model-enhancements__table_ndx_lsr_3gb}Total Release Capacity = 90+ 160 = 250 points