Mixing
Scrum for SDK development - split stories horizontally?
Our product is moving more and more in the direction of a software development kit (SDK) which can be used by other developers.
This brings up quite some challenges to our agile processes, though and I am searching for suggestions from people who have experience with this.
The main question we are struggling with is: how to split user stories, since we are disagreeing on who our user is. Are we planning for features from an end-user perspective (we currently ship the SDK together with a standard implementation, so everything actually has UI, etc. but customers can also adjust this standard behaviour to their needs) or is it enough to define a ticket in terms of "There should be a method in class X doing Y"?
In "normal" Scrum Teams, it's a bad practice to split user stories by horizontal layers but some team members argue that if we consider the SDK consumer as a user, then a ticket "There should be a method in class X doing Y" should be valid and that a separate ticket for UI for the same feature can be created since that one targets a different user/use-case.
I hope I explained well enough to give you a good understanding. I am happy to hear your thoughts, experiences and suggestions!
scrum software-development user-stories development-process
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
add a comment |
Our product is moving more and more in the direction of a software development kit (SDK) which can be used by other developers.
This brings up quite some challenges to our agile processes, though and I am searching for suggestions from people who have experience with this.
The main question we are struggling with is: how to split user stories, since we are disagreeing on who our user is. Are we planning for features from an end-user perspective (we currently ship the SDK together with a standard implementation, so everything actually has UI, etc. but customers can also adjust this standard behaviour to their needs) or is it enough to define a ticket in terms of "There should be a method in class X doing Y"?
In "normal" Scrum Teams, it's a bad practice to split user stories by horizontal layers but some team members argue that if we consider the SDK consumer as a user, then a ticket "There should be a method in class X doing Y" should be valid and that a separate ticket for UI for the same feature can be created since that one targets a different user/use-case.
I hope I explained well enough to give you a good understanding. I am happy to hear your thoughts, experiences and suggestions!
scrum software-development user-stories development-process
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
add a comment |
Our product is moving more and more in the direction of a software development kit (SDK) which can be used by other developers.
This brings up quite some challenges to our agile processes, though and I am searching for suggestions from people who have experience with this.
The main question we are struggling with is: how to split user stories, since we are disagreeing on who our user is. Are we planning for features from an end-user perspective (we currently ship the SDK together with a standard implementation, so everything actually has UI, etc. but customers can also adjust this standard behaviour to their needs) or is it enough to define a ticket in terms of "There should be a method in class X doing Y"?
In "normal" Scrum Teams, it's a bad practice to split user stories by horizontal layers but some team members argue that if we consider the SDK consumer as a user, then a ticket "There should be a method in class X doing Y" should be valid and that a separate ticket for UI for the same feature can be created since that one targets a different user/use-case.
I hope I explained well enough to give you a good understanding. I am happy to hear your thoughts, experiences and suggestions!
scrum software-development user-stories development-process
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
Our product is moving more and more in the direction of a software development kit (SDK) which can be used by other developers.
This brings up quite some challenges to our agile processes, though and I am searching for suggestions from people who have experience with this.
The main question we are struggling with is: how to split user stories, since we are disagreeing on who our user is. Are we planning for features from an end-user perspective (we currently ship the SDK together with a standard implementation, so everything actually has UI, etc. but customers can also adjust this standard behaviour to their needs) or is it enough to define a ticket in terms of "There should be a method in class X doing Y"?
In "normal" Scrum Teams, it's a bad practice to split user stories by horizontal layers but some team members argue that if we consider the SDK consumer as a user, then a ticket "There should be a method in class X doing Y" should be valid and that a separate ticket for UI for the same feature can be created since that one targets a different user/use-case.
I hope I explained well enough to give you a good understanding. I am happy to hear your thoughts, experiences and suggestions!
scrum software-development user-stories development-process
scrum software-development user-stories development-process
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
edited Jan 31 at 9:37
Danny Schoemann
2,15211637
2,15211637
asked Jan 30 at 14:22
fridayfriday
1233
asked Jan 30 at 14:22
fridayfriday
1233
asked Jan 30 at 14:22
fridayfriday
1233
1233
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.
So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.
Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.
In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.
User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.
Run an experiment for 3-4 timeboxes and see how the team react.
Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
add a comment |
Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:
As an SDK user, I would like to be able to grant permissions to a user
so that I can manage what different users can do.
and
As an interface user, I would like to be able to grant permissions to
a user so that I can manage what different users can do.
Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.
answered Jan 30 at 15:17
DanielDaniel
9,48821327
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%2f25719%2fscrum-for-sdk-development-split-stories-horizontally%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.
So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.
Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.
In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.
User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.
Run an experiment for 3-4 timeboxes and see how the team react.
Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
add a comment |
Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.
So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.
Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.
In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.
User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.
Run an experiment for 3-4 timeboxes and see how the team react.
Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
add a comment |
Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.
So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.
Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.
In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.
User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.
Run an experiment for 3-4 timeboxes and see how the team react.
Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
Remember that very few patterns we consider to be Agile are scientific rules. They are art applied scientifically.
So, while Use Stories are supposed to be split vertically offering a complete slice of production-ready code, that is not always the case.
Mike Cohn himself has demonstrated a number of case studies from industries that have adapted patterns to work effectively. For instance, game development can have four levels of done.
In your specific example, let the team decide the most effective way of dissecting user requirements and packaging them for development/deployment.
User Story verticalisation works amazingly well in eCommerce or B2C applications and websites but less well in environments with highly coupled dependencies.
Run an experiment for 3-4 timeboxes and see how the team react.
Don't maintain allegiance to any delivery pattern that is causing you pain. The only metric is quality software, delivered regularly under sustainable conditions.
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
answered Jan 30 at 15:07
Venture2099Venture2099
2,851828
2,851828
add a comment |
add a comment |
Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:
As an SDK user, I would like to be able to grant permissions to a user
so that I can manage what different users can do.
and
As an interface user, I would like to be able to grant permissions to
a user so that I can manage what different users can do.
Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.
answered Jan 30 at 15:17
DanielDaniel
9,48821327
add a comment |
Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:
As an SDK user, I would like to be able to grant permissions to a user
so that I can manage what different users can do.
and
As an interface user, I would like to be able to grant permissions to
a user so that I can manage what different users can do.
Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.
answered Jan 30 at 15:17
DanielDaniel
9,48821327
add a comment |
Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:
As an SDK user, I would like to be able to grant permissions to a user
so that I can manage what different users can do.
and
As an interface user, I would like to be able to grant permissions to
a user so that I can manage what different users can do.
Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.
answered Jan 30 at 15:17
DanielDaniel
9,48821327
Keep in mind that different stories can have different users. If you are building you UI off of your own SDK, it isn't uncommon to have these two use stories:
As an SDK user, I would like to be able to grant permissions to a user
so that I can manage what different users can do.
and
As an interface user, I would like to be able to grant permissions to
a user so that I can manage what different users can do.
Doing the first one first makes the second one much smaller. Both of them deliver real end-to-end value to a user. The only thing that is grey is if they are truly independent. I would argue that they are, because it is possible to do either first, it just wouldn't usually make sense to do the second one first. It could though. If the UI users really needed something fast, I could focus on that and shortcut all of the work and testing that would go into making it available through the SDK - it would just be architecturally far less sound.
answered Jan 30 at 15:17
DanielDaniel
9,48821327
answered Jan 30 at 15:17
DanielDaniel
9,48821327
answered Jan 30 at 15:17
DanielDaniel
9,48821327
answered Jan 30 at 15:17
DanielDaniel
9,48821327
9,48821327
add a comment |
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%2f25719%2fscrum-for-sdk-development-split-stories-horizontally%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
