Sprint board critique
We are a DevOps software team with dependencies upon a release process which often requires us to wait before releasing some code to production for up to 5 times longer than our sprint length. This causes stories to either remain on our board or go onto a hidden board, neither are a suitable use case.
We have recently had a new board layout imparted upon our team. While our previous column layout was not the greatest, I have reservations about this new one.
While every team is different, I was hoping to get a critique of this board layout by anyone who might be sympathetic to the scenario above, and perhaps some advice on how better to lay it out. Our board columns are:
- Draft
- Awaiting Info
- Estimation
- Ready
- Work in progress
- Ready for testing
- Testing
- Testing failed
- Ready for deployment
- Complete
- Cancelled
11 columns is a lot and I would much rather use more standard agile terms. For example, Done and To Do are completely absent, here.
scrum agile sprint-planning board
add a comment |
We are a DevOps software team with dependencies upon a release process which often requires us to wait before releasing some code to production for up to 5 times longer than our sprint length. This causes stories to either remain on our board or go onto a hidden board, neither are a suitable use case.
We have recently had a new board layout imparted upon our team. While our previous column layout was not the greatest, I have reservations about this new one.
While every team is different, I was hoping to get a critique of this board layout by anyone who might be sympathetic to the scenario above, and perhaps some advice on how better to lay it out. Our board columns are:
- Draft
- Awaiting Info
- Estimation
- Ready
- Work in progress
- Ready for testing
- Testing
- Testing failed
- Ready for deployment
- Complete
- Cancelled
11 columns is a lot and I would much rather use more standard agile terms. For example, Done and To Do are completely absent, here.
scrum agile sprint-planning board
add a comment |
We are a DevOps software team with dependencies upon a release process which often requires us to wait before releasing some code to production for up to 5 times longer than our sprint length. This causes stories to either remain on our board or go onto a hidden board, neither are a suitable use case.
We have recently had a new board layout imparted upon our team. While our previous column layout was not the greatest, I have reservations about this new one.
While every team is different, I was hoping to get a critique of this board layout by anyone who might be sympathetic to the scenario above, and perhaps some advice on how better to lay it out. Our board columns are:
- Draft
- Awaiting Info
- Estimation
- Ready
- Work in progress
- Ready for testing
- Testing
- Testing failed
- Ready for deployment
- Complete
- Cancelled
11 columns is a lot and I would much rather use more standard agile terms. For example, Done and To Do are completely absent, here.
scrum agile sprint-planning board
We are a DevOps software team with dependencies upon a release process which often requires us to wait before releasing some code to production for up to 5 times longer than our sprint length. This causes stories to either remain on our board or go onto a hidden board, neither are a suitable use case.
We have recently had a new board layout imparted upon our team. While our previous column layout was not the greatest, I have reservations about this new one.
While every team is different, I was hoping to get a critique of this board layout by anyone who might be sympathetic to the scenario above, and perhaps some advice on how better to lay it out. Our board columns are:
- Draft
- Awaiting Info
- Estimation
- Ready
- Work in progress
- Ready for testing
- Testing
- Testing failed
- Ready for deployment
- Complete
- Cancelled
11 columns is a lot and I would much rather use more standard agile terms. For example, Done and To Do are completely absent, here.
scrum agile sprint-planning board
scrum agile sprint-planning board
asked Jan 28 at 13:10
Matt WMatt W
449110
449110
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
Queuing Stages
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
Short-lived Stages
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
Final Thoughts
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
Glad to hear it
– Daniel
Jan 28 at 17:57
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/3.0/"u003ecc by-sa 3.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%2f25698%2fsprint-board-critique%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
Queuing Stages
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
Short-lived Stages
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
Final Thoughts
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
Glad to hear it
– Daniel
Jan 28 at 17:57
add a comment |
If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
Queuing Stages
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
Short-lived Stages
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
Final Thoughts
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
Glad to hear it
– Daniel
Jan 28 at 17:57
add a comment |
If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
Queuing Stages
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
Short-lived Stages
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
Final Thoughts
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.
If I read this correctly, you are asking about your board / workflow design rather than the overall circumstances in Scrum, so I'll focus my answer on that.
First, when designing a workflow, especially more complicated ones like this, the benefit comes from matching your process. Since I don't know your process, I don't know how closely this matches it so I can't say if it succeeds in that regard. I can, however, identify a few common patterns I've seen elsewhere that you should consider.
Queuing Stages
As a rule, queuing stages are problematic because no one is doing anything in them. A big red flag that something is a queueing stage is that it starts with "Ready For". When we have queueing stages in our system, this means that either we want things to sit around with no one working on them (pretty rare), or we're trying to hide a bottleneck.
As an example here, you have a development stage followed by a testing stage. No action happens between the two so there should be no stage between the two. Typically when I see this in boards, it is so the developers can move faster than the testers, which is local optimization at the expense of global sub-optimization (or to take the jargon out, we slow down the actual completion of work to make ourselves look better).
If I want a visual indicator that something is ready to be pulled to the next stage, I usually recommend changing the card color or adding an icon in electronic tools and just a magnet or sticker on a physical board. Or, to be a bit more pedantic, team members could just talk to each other.
Short-lived Stages
I'll pick on estimation for this one. I'd be curious what value you get out of the estimation stage. Usually estimation is a quick conversation and when I see these in other teams, a lot of times the team is done with the task before they even remember to move the card. For most teams, "Work must be estimated" could just be a policy for a card to move from Draft to Ready. Of course, I could be completely wrong. It isn't common, but some teams benefit from robust estimation techniques that warrant this being its own stage. Your team needs to make that decision for themselves.
Testing Failed and Cancelled
These just feel odd to me. They feel like information more than workflow. I feel like I could just put a red dot on the card and completely eliminate the need for these stages entirely. My biggest concern when I see stages like this is that they are often used to set aside cards that would otherwise "look bad" on the board. Again, decide for yourself if these add value.
Final Thoughts
I feel like this board could be:
Draft - Development - Testing - Deploying - Done
and you could use other visual indicators to show the extra information. But, it's your board and you know what really happens in your team. When I coach teams, I usually say that I'll never tell them their board is wrong, but they should always ask themselves if visualizing their work in a certain way teaches them something they can use to improve how they work. If so, it is doing its job.
answered Jan 28 at 15:12
DanielDaniel
8,58921025
8,58921025
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
Glad to hear it
– Daniel
Jan 28 at 17:57
add a comment |
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
Glad to hear it
– Daniel
Jan 28 at 17:57
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
Thank you - you have somehow crystallised what I've been trying to put into words but could only emote until now.
– Matt W
Jan 28 at 16:59
1
1
Glad to hear it
– Daniel
Jan 28 at 17:57
Glad to hear it
– Daniel
Jan 28 at 17:57
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%2f25698%2fsprint-board-critique%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