---
sourceDocument: Yokohama Strategic Portfolio Management
sourceDocumentLink: https://www.servicenow.com/docs/r/yokohama/it-business-management

 Release :

    - yokohama

ft:locale :

    - en-US

ft:publication_title :

    - Yokohama 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: Yokohama
* 
* Updated October 23, 2025
* 
* ![](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 enhancements compared to Agile Development 1.0.
Key changes include the deprecation of features from 1.0, such as the Sprint and Release Burndown charts, and the adoption of a more streamlined approach using Assignment Groups for agile teams.
Show full answer Show less  

## Key Features

* **Common Platform Construct:** Agile Development 2.0 standardizes the use of Assignment Groups to map agile teams, eliminating the need for a separate Release Team entity.
* **Independent Group Creation:** Teams can now be created independently of releases. This allows agile teams to work on multiple releases without the need to recreate the team for each one.
* **Sprints Without Releases:** Sprints can be created without a mandatory release, providing more flexibility in managing story execution.
* **Ongoing Team Backlog:** Teams can maintain a continuous backlog independent of releases, allowing for better organization and execution of stories across multiple releases.
* **New Association Table:** The m2mreleasegrouplist table has been introduced to manage associations between groups and releases, helping to derive release capacity without affecting sprint generation.

## Key Outcomes

By transitioning to Agile Development 2.0, customers can expect improved agility and efficiency in managing their agile processes. The ability to create teams and sprints independently of releases enhances flexibility, while the new association table aids in tracking team capacities across various releases, ultimately leading to better resource management and project delivery.  
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](https://www.servicenow.com/docs/3zOOAnAuMmWKu~XsJgK1Iw "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.

## Use of the common platform construct --- Assignment Group {#data-model-enhancements__section_d5f_gb4_4hc}

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

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

## 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.Figure 3. Scrum 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.Figure 4. Sprints 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.  
Figure 5. Group backlog with Agile Development 2.0

## 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

