We have 15 development teams (Scrum teams). Each team has a PM (product owner).
On paper, all the teams are fungible. In practice, each team has an area of expertise and "owns" that functionality.
The PM of each team prioritizes big features, small features, and bugs. The team carves out 2 weeks (a sprint) of work items from that prioritized backlog.
Ship dates are set far in advance. Those dates are set in stone.
Features are pencilled in on the calendar for when they will be worked on, and how long they will take. This schedule is a WAG for planning purposes, and subject to revision over the course of the cycle.
The council of PMs have a grid of all the features (big and small) across all teams, and track the status of those features. The status being: on track, concerned, in trouble. Features that are on track and finished for the release will ship. Features that were incomplete have to wait for the next shipping date.
Ostensibly, each team is using by-the-book Scrum as a lightweight management process. But in actuality, each team does "Scrum, but..." which is at some variance from by-the-book Scrum.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How do you define what would be included for each release?
We have 15 development teams (Scrum teams). Each team has a PM (product owner).
On paper, all the teams are fungible. In practice, each team has an area of expertise and "owns" that functionality.
The PM of each team prioritizes big features, small features, and bugs. The team carves out 2 weeks (a sprint) of work items from that prioritized backlog.
Ship dates are set far in advance. Those dates are set in stone.
Features are pencilled in on the calendar for when they will be worked on, and how long they will take. This schedule is a WAG for planning purposes, and subject to revision over the course of the cycle.
The council of PMs have a grid of all the features (big and small) across all teams, and track the status of those features. The status being: on track, concerned, in trouble. Features that are on track and finished for the release will ship. Features that were incomplete have to wait for the next shipping date.
Ostensibly, each team is using by-the-book Scrum as a lightweight management process. But in actuality, each team does "Scrum, but..." which is at some variance from by-the-book Scrum.