- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-02-2018 04:37 AM
Hi,
With Jakarta Agile Development 1.0 has been replaced by Agile Development 2.0.
In Agile Development 1.0 we usually created a Release, than split it up and several sprints. I recognized that in Agile Development 2.0 the relationship between sprints and releases has been removed.. This is a quote from the Jakarta Release Notes:
The following changes are implemented as part of the Agile Development 2.0 plugin and are not applicable to the Agile Development plugin.
- Release Team: Release team has been removed. Assignment Group of type Agile team is available for use.
- Sprints: Sprints are no longer associated to a release, they are instead associated to an assignment group.
Can anybody explain why this paradigm change has been made? I don't really understand the benefit. I more feel like Releases should be split up in sprints, and than a sprint can have multiple groups (e.g. the work might be delivered by different contractors and each of them has an own assignment group).
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-02-2018 02:31 PM
Hello,
The best way I can explain it is over the five years I've been using Agile (as a customer), we found that we did not want to tie sprints to releases for a couple reasons. One, we were doing shorter release cycles which made it one sprint per release, which was redundant. Second, the sprint represented the timeframe we completed the stories and then they sat on the shelf (in Test) until the Product Owner was ready to release them. The stories were complete and the sprints complete, but the release stayed open indefinitely, or until the stories went to production. Then we found releases started picking up stories from other sprints and that didn't make sense. For this reason we stopped using Releases and would just complete the stories within a sprint, complete the sprint, and then link the stories to a change record when they were going to production. I would assume ServiceNow product team has heard something similar from many other customers, which is why they have shifted. Does that help?
Regards,
Jay
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎03-02-2018 02:31 PM
Hello,
The best way I can explain it is over the five years I've been using Agile (as a customer), we found that we did not want to tie sprints to releases for a couple reasons. One, we were doing shorter release cycles which made it one sprint per release, which was redundant. Second, the sprint represented the timeframe we completed the stories and then they sat on the shelf (in Test) until the Product Owner was ready to release them. The stories were complete and the sprints complete, but the release stayed open indefinitely, or until the stories went to production. Then we found releases started picking up stories from other sprints and that didn't make sense. For this reason we stopped using Releases and would just complete the stories within a sprint, complete the sprint, and then link the stories to a change record when they were going to production. I would assume ServiceNow product team has heard something similar from many other customers, which is why they have shifted. Does that help?
Regards,
Jay
