Reducing Spill Overs
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{
margin-bottom:0;
}
.everyonelovesstackoverflow{position:absolute;height:1px;width:1px;opacity:0;top:0;left:0;pointer-events:none;}
The scrum team performs following tasks
- Development -- Dev Team
- Testing -- Test team
- Merging -- Senior Team [BOTTLE NECK]
- Acceptance Testing -- PO/BA [BOTTLE NECK]
The Dev and Test team finishes the tasks as per the plan however availability of PO and Senior team is an issue. Senior team is busy with their planned activities so they delay the merging. Sometimes the stories are not closed because PO cannot verify the story or find out the issues pretty late.
So during this period, rather than waiting for senior/PO, developers start working on next stories and that results in large number of committed stories while the delivered stories are always less than committed but almost constant from last few sprints.
Due to these dependencies and bottleneck the few stories spill over to next sprint. I am sure this is not the unique scenario but your experience might help me.
scrum scrum-master sprint-planning
add a comment
|
The scrum team performs following tasks
- Development -- Dev Team
- Testing -- Test team
- Merging -- Senior Team [BOTTLE NECK]
- Acceptance Testing -- PO/BA [BOTTLE NECK]
The Dev and Test team finishes the tasks as per the plan however availability of PO and Senior team is an issue. Senior team is busy with their planned activities so they delay the merging. Sometimes the stories are not closed because PO cannot verify the story or find out the issues pretty late.
So during this period, rather than waiting for senior/PO, developers start working on next stories and that results in large number of committed stories while the delivered stories are always less than committed but almost constant from last few sprints.
Due to these dependencies and bottleneck the few stories spill over to next sprint. I am sure this is not the unique scenario but your experience might help me.
scrum scrum-master sprint-planning
2
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46
add a comment
|
The scrum team performs following tasks
- Development -- Dev Team
- Testing -- Test team
- Merging -- Senior Team [BOTTLE NECK]
- Acceptance Testing -- PO/BA [BOTTLE NECK]
The Dev and Test team finishes the tasks as per the plan however availability of PO and Senior team is an issue. Senior team is busy with their planned activities so they delay the merging. Sometimes the stories are not closed because PO cannot verify the story or find out the issues pretty late.
So during this period, rather than waiting for senior/PO, developers start working on next stories and that results in large number of committed stories while the delivered stories are always less than committed but almost constant from last few sprints.
Due to these dependencies and bottleneck the few stories spill over to next sprint. I am sure this is not the unique scenario but your experience might help me.
scrum scrum-master sprint-planning
The scrum team performs following tasks
- Development -- Dev Team
- Testing -- Test team
- Merging -- Senior Team [BOTTLE NECK]
- Acceptance Testing -- PO/BA [BOTTLE NECK]
The Dev and Test team finishes the tasks as per the plan however availability of PO and Senior team is an issue. Senior team is busy with their planned activities so they delay the merging. Sometimes the stories are not closed because PO cannot verify the story or find out the issues pretty late.
So during this period, rather than waiting for senior/PO, developers start working on next stories and that results in large number of committed stories while the delivered stories are always less than committed but almost constant from last few sprints.
Due to these dependencies and bottleneck the few stories spill over to next sprint. I am sure this is not the unique scenario but your experience might help me.
scrum scrum-master sprint-planning
scrum scrum-master sprint-planning
edited May 27 at 10:11
Ram
asked May 27 at 8:39
RamRam
1163 bronze badges
1163 bronze badges
2
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46
add a comment
|
2
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46
2
2
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46
add a comment
|
4 Answers
4
active
oldest
votes
Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary:
Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look different from mine. But what you need to do is make it visible. Have a column on your board or a tag in your system or whatever you use. Make sure it's visible that there is a bottleneck and everyone knows about it in the standup. And if senior people decide that they have more important things to do, then the story will not get done. You cannot do more than notify the people responsible. Don't forget to lower the velocity when you did not finish tickets so you don't get the same problem next sprint.
After a while, the senior people will get into problems with management on why their team is delivering so slowly and will see the need to optimize this, too.
In an ideal world, they would see it from the get go, but unless you know an ideal company you could switch too, you will be stuck with the real world :)
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
add a comment
|
The bottlenecks are known so the first thing is to bring them to a Retrospective, as was already suggested. Try to find the root-cause of why they're seen as bottlenecks. Why do they have to hold back the entire development process?
Otherwise, I would say that there's apparently an over-commitment. If there are bottlenecks, it's because it's been proven that the team has less capacity than the demand of the work thrown on them. So, reduce the Work In Progress (WIP) so that things can get done. Once bottlenecks are improving, increase the WIP limits as you go along.
add a comment
|
I feel there is an issue in sprint planning itself because as part of retrospective meeting, we know the progress of previous sprint and team commitment, so this has to be addressed for the upcoming sprints.
add a comment
|
Your dev team is too big.
More accurately, it is providing too many developer-hours.
This is a great problem to have; there's always other projects and teams that need more resourcing.
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
add a comment
|
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "208"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/4.0/"u003ecc by-sa 4.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f26500%2freducing-spill-overs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
4 Answers
4
active
oldest
votes
4 Answers
4
active
oldest
votes
active
oldest
votes
active
oldest
votes
Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary:
Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look different from mine. But what you need to do is make it visible. Have a column on your board or a tag in your system or whatever you use. Make sure it's visible that there is a bottleneck and everyone knows about it in the standup. And if senior people decide that they have more important things to do, then the story will not get done. You cannot do more than notify the people responsible. Don't forget to lower the velocity when you did not finish tickets so you don't get the same problem next sprint.
After a while, the senior people will get into problems with management on why their team is delivering so slowly and will see the need to optimize this, too.
In an ideal world, they would see it from the get go, but unless you know an ideal company you could switch too, you will be stuck with the real world :)
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
add a comment
|
Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary:
Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look different from mine. But what you need to do is make it visible. Have a column on your board or a tag in your system or whatever you use. Make sure it's visible that there is a bottleneck and everyone knows about it in the standup. And if senior people decide that they have more important things to do, then the story will not get done. You cannot do more than notify the people responsible. Don't forget to lower the velocity when you did not finish tickets so you don't get the same problem next sprint.
After a while, the senior people will get into problems with management on why their team is delivering so slowly and will see the need to optimize this, too.
In an ideal world, they would see it from the get go, but unless you know an ideal company you could switch too, you will be stuck with the real world :)
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
add a comment
|
Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary:
Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look different from mine. But what you need to do is make it visible. Have a column on your board or a tag in your system or whatever you use. Make sure it's visible that there is a bottleneck and everyone knows about it in the standup. And if senior people decide that they have more important things to do, then the story will not get done. You cannot do more than notify the people responsible. Don't forget to lower the velocity when you did not finish tickets so you don't get the same problem next sprint.
After a while, the senior people will get into problems with management on why their team is delivering so slowly and will see the need to optimize this, too.
In an ideal world, they would see it from the get go, but unless you know an ideal company you could switch too, you will be stuck with the real world :)
Those "phases" you describe sound very non-agile to me, but there are instances where a single person cannot complete a story and needs help from another team member even in super-agile environments, so lets just assume it is indeed necessary:
Take those points and discuss them in the next retrospective. There is no silver bullet, you solution will look different from mine. But what you need to do is make it visible. Have a column on your board or a tag in your system or whatever you use. Make sure it's visible that there is a bottleneck and everyone knows about it in the standup. And if senior people decide that they have more important things to do, then the story will not get done. You cannot do more than notify the people responsible. Don't forget to lower the velocity when you did not finish tickets so you don't get the same problem next sprint.
After a while, the senior people will get into problems with management on why their team is delivering so slowly and will see the need to optimize this, too.
In an ideal world, they would see it from the get go, but unless you know an ideal company you could switch too, you will be stuck with the real world :)
answered May 27 at 9:17
nvoigtnvoigt
4,92810 silver badges20 bronze badges
4,92810 silver badges20 bronze badges
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
add a comment
|
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
Thanks, however suppose I have 2 more days to close the sprint then developer picks the new story. Not always he can close it by end of the sprint and that result in spillover. Not sure how to avoid this.
– Ram
May 28 at 6:00
3
3
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
@Ram Maybe the developer can help somebody else instead of picking a story they cannot finish. The focus is on finishing stories, not starting as many as possible. In the end, you cannot completely avoid spillover every sprint. You just have to make it visible and adjust the velocity accordingly.
– nvoigt
May 28 at 6:13
add a comment
|
The bottlenecks are known so the first thing is to bring them to a Retrospective, as was already suggested. Try to find the root-cause of why they're seen as bottlenecks. Why do they have to hold back the entire development process?
Otherwise, I would say that there's apparently an over-commitment. If there are bottlenecks, it's because it's been proven that the team has less capacity than the demand of the work thrown on them. So, reduce the Work In Progress (WIP) so that things can get done. Once bottlenecks are improving, increase the WIP limits as you go along.
add a comment
|
The bottlenecks are known so the first thing is to bring them to a Retrospective, as was already suggested. Try to find the root-cause of why they're seen as bottlenecks. Why do they have to hold back the entire development process?
Otherwise, I would say that there's apparently an over-commitment. If there are bottlenecks, it's because it's been proven that the team has less capacity than the demand of the work thrown on them. So, reduce the Work In Progress (WIP) so that things can get done. Once bottlenecks are improving, increase the WIP limits as you go along.
add a comment
|
The bottlenecks are known so the first thing is to bring them to a Retrospective, as was already suggested. Try to find the root-cause of why they're seen as bottlenecks. Why do they have to hold back the entire development process?
Otherwise, I would say that there's apparently an over-commitment. If there are bottlenecks, it's because it's been proven that the team has less capacity than the demand of the work thrown on them. So, reduce the Work In Progress (WIP) so that things can get done. Once bottlenecks are improving, increase the WIP limits as you go along.
The bottlenecks are known so the first thing is to bring them to a Retrospective, as was already suggested. Try to find the root-cause of why they're seen as bottlenecks. Why do they have to hold back the entire development process?
Otherwise, I would say that there's apparently an over-commitment. If there are bottlenecks, it's because it's been proven that the team has less capacity than the demand of the work thrown on them. So, reduce the Work In Progress (WIP) so that things can get done. Once bottlenecks are improving, increase the WIP limits as you go along.
edited May 27 at 15:24
Sarov
9,9524 gold badges22 silver badges43 bronze badges
9,9524 gold badges22 silver badges43 bronze badges
answered May 27 at 15:04
Alex EstevamAlex Estevam
212 bronze badges
212 bronze badges
add a comment
|
add a comment
|
I feel there is an issue in sprint planning itself because as part of retrospective meeting, we know the progress of previous sprint and team commitment, so this has to be addressed for the upcoming sprints.
add a comment
|
I feel there is an issue in sprint planning itself because as part of retrospective meeting, we know the progress of previous sprint and team commitment, so this has to be addressed for the upcoming sprints.
add a comment
|
I feel there is an issue in sprint planning itself because as part of retrospective meeting, we know the progress of previous sprint and team commitment, so this has to be addressed for the upcoming sprints.
I feel there is an issue in sprint planning itself because as part of retrospective meeting, we know the progress of previous sprint and team commitment, so this has to be addressed for the upcoming sprints.
answered May 28 at 8:46
Karthikeyan DevarajKarthikeyan Devaraj
186 bronze badges
186 bronze badges
add a comment
|
add a comment
|
Your dev team is too big.
More accurately, it is providing too many developer-hours.
This is a great problem to have; there's always other projects and teams that need more resourcing.
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
add a comment
|
Your dev team is too big.
More accurately, it is providing too many developer-hours.
This is a great problem to have; there's always other projects and teams that need more resourcing.
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
add a comment
|
Your dev team is too big.
More accurately, it is providing too many developer-hours.
This is a great problem to have; there's always other projects and teams that need more resourcing.
Your dev team is too big.
More accurately, it is providing too many developer-hours.
This is a great problem to have; there's always other projects and teams that need more resourcing.
answered May 28 at 17:14
RogerRoger
1334 bronze badges
1334 bronze badges
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
add a comment
|
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
The team would only provide too many developer hours, if they ran out of stories to do.
– nvoigt
May 29 at 5:40
add a comment
|
Thanks for contributing an answer to Project Management Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fpm.stackexchange.com%2fquestions%2f26500%2freducing-spill-overs%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
I tagged this as Scrum instead of the more general "agile" because you said you were a Scrum team. Feel free to roll this change back if I misunderstood you.
– nvoigt
May 27 at 9:11
Stories should never "spill over." Incomplete stories go back onto the Product Backlog to be re-estimated, re-prioritized, and re-planned—assuming they even remain necessary to the project at all, of course.
– Todd A. Jacobs♦
May 27 at 14:45
How are these unfinished stories impacting your Sprint Goal each Sprint?
– Todd A. Jacobs♦
May 27 at 14:46