Phenomenal breakdown. I've used all of these methods and find them quite effective. Sometimes I've found reason to split user stories based on related code, features, or external dependencies. For example, creating a LinkedIn competitor might involve a User Profile page (story 1) and a Resume Repository (story 2). Both involve file uploads, so I'd split out the user profile image upload to story 3. This is very similar to Paths but comes from a different motivation. Perhaps story 1 fits into sprint 1, while stories 2 and 3 wait for sprint 2. So for sprint 1, I have no infrastructure dependencies, but for sprint 2 I may have multiple infrastructure requests. Yes, user stories are generally agnostic of implementation details, such as what code is being touched, but sometimes that knowledge can assist in planning and definitely impacts estimating. And when changes involve external dependencies, isolating and grouping those seems to be more effective, in my experience.
Regardless of how you split stories, it is still up to the Product Owner whether to release them collectively or incrementally. The beauty of splitting though is more on the development side which makes it easier to build at an earlier time.
You're right that it's ultimately the POs decision to release and the size of releases there are a few other benefits to splitting stories. Smaller stories, by definition, require less effort to complete which, like you said, makes it easier to build. We can also split a story to learn more about the story. Splitting it makes it easier to identify what skills we don't have. That's where the S in SPIDR comes in. We can use a spike to learn a new skill to tackle the rest of the big story. Splitting stories can also lead to new ideas. Like in the Path example in the video. The first thing that comes to mind for me when I read "share the video" is to provide a link that I can post wherever I would like. But splitting that story into "share on social" opens the door to several different sharing options that I didn't think of before.
In case of data warehouse housing development requirement, is it fine to have different user stories ( mapping, development, testing, deployment) because it is not possible to complete the full requirement in one sprint
Mike, I just had a thought. If you'll forgive my impertinence, perhaps there's a U that might turn it into "SPIDUR", which is to serve one group of the user community. Would that make sense or would I simply be making it too complex?
That's a really promising idea, Stephen. I'm not sure it would lead me to any splits I wouldn't think of with the current five BUT it might get me to a split more quickly. As I think through examples there are easy ones like user/admin but those are super simple to split. But then I think about more subtle user differences--perhaps something like an occasional eBay seller (once a year) vs someone selling fulltime. I guess I'd probably start those as separate stories, though. So, it could be a good way to more quickly get to a good split. Great idea.
I agree 100%, and would even go so far as to make the U reflect "User Persona" - in healthcare software, I find that a single feature or enhancement will have different requirements based on which user / staff person is working with it, i.e. Administrative users, Clinical users, Front office users, etc.
@@StaceySteinbach Keep in mind that with a user story this will almost always be reflected in the start of the story: “As an administrative user….” Or “As a front office user…”. So the user persona is already there as the primary differentiator of most user stories.
Throughout the video you talk pretty much exclusively about user stories. At the end however, you mention "job" stories. What are those? I thought all stories should be from the user perspective.
Good question! Job stories are an alternative to user stories and are used when the type of user doesn't really matter. A job story is focused less on the user performing some function than on the job to be done by that story. If you find yourself using the generic "As a user" in your user stories that's a good indication that you should use a job story. You don't really care who the user is because the job being done by the story is the important part. Imagine driving a car. It doesn't matter if it's my first time driving a car or my hundredth time. It doesn't matter if I am 16 or 106. It doesn't matter if I have good eyesight or bad eyesight. When I press on the brake, the car should slow down. Every car should slow down when the brake is pressed regardless of who is pressing the break. So I would use a job story and say "When I press on the brake I want to slow down so I can come to a safe stop." If you want to learn more about job stories we have a great introduction here: www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories
Phenomenal breakdown. I've used all of these methods and find them quite effective.
Sometimes I've found reason to split user stories based on related code, features, or external dependencies. For example, creating a LinkedIn competitor might involve a User Profile page (story 1) and a Resume Repository (story 2). Both involve file uploads, so I'd split out the user profile image upload to story 3. This is very similar to Paths but comes from a different motivation. Perhaps story 1 fits into sprint 1, while stories 2 and 3 wait for sprint 2. So for sprint 1, I have no infrastructure dependencies, but for sprint 2 I may have multiple infrastructure requests.
Yes, user stories are generally agnostic of implementation details, such as what code is being touched, but sometimes that knowledge can assist in planning and definitely impacts estimating. And when changes involve external dependencies, isolating and grouping those seems to be more effective, in my experience.
Good point.
Regardless of how you split stories, it is still up to the Product Owner whether to release them collectively or incrementally. The beauty of splitting though is more on the development side which makes it easier to build at an earlier time.
You're right that it's ultimately the POs decision to release and the size of releases there are a few other benefits to splitting stories. Smaller stories, by definition, require less effort to complete which, like you said, makes it easier to build. We can also split a story to learn more about the story. Splitting it makes it easier to identify what skills we don't have. That's where the S in SPIDR comes in. We can use a spike to learn a new skill to tackle the rest of the big story. Splitting stories can also lead to new ideas. Like in the Path example in the video. The first thing that comes to mind for me when I read "share the video" is to provide a link that I can post wherever I would like. But splitting that story into "share on social" opens the door to several different sharing options that I didn't think of before.
Hi Mike. I love your SPIDR model!
Thanks, Coach--and I appreciate your User idea above--or below, depending on how UA-cam sorts things at the moment. :)
In case of data warehouse housing development requirement, is it fine to have different user stories ( mapping, development, testing, deployment) because it is not possible to complete the full requirement in one sprint
If that is working for you, keep doing it.
Mike, I just had a thought. If you'll forgive my impertinence, perhaps there's a U that might turn it into "SPIDUR", which is to serve one group of the user community. Would that make sense or would I simply be making it too complex?
That's a really promising idea, Stephen. I'm not sure it would lead me to any splits I wouldn't think of with the current five BUT it might get me to a split more quickly.
As I think through examples there are easy ones like user/admin but those are super simple to split. But then I think about more subtle user differences--perhaps something like an occasional eBay seller (once a year) vs someone selling fulltime. I guess I'd probably start those as separate stories, though.
So, it could be a good way to more quickly get to a good split. Great idea.
I agree 100%, and would even go so far as to make the U reflect "User Persona" - in healthcare software, I find that a single feature or enhancement will have different requirements based on which user / staff person is working with it, i.e. Administrative users, Clinical users, Front office users, etc.
@@StaceySteinbach Keep in mind that with a user story this will almost always be reflected in the start of the story: “As an administrative user….” Or “As a front office user…”. So the user persona is already there as the primary differentiator of most user stories.
Throughout the video you talk pretty much exclusively about user stories. At the end however, you mention "job" stories. What are those? I thought all stories should be from the user perspective.
Good question! Job stories are an alternative to user stories and are used when the type of user doesn't really matter. A job story is focused less on the user performing some function than on the job to be done by that story. If you find yourself using the generic "As a user" in your user stories that's a good indication that you should use a job story. You don't really care who the user is because the job being done by the story is the important part.
Imagine driving a car. It doesn't matter if it's my first time driving a car or my hundredth time. It doesn't matter if I am 16 or 106. It doesn't matter if I have good eyesight or bad eyesight. When I press on the brake, the car should slow down. Every car should slow down when the brake is pressed regardless of who is pressing the break. So I would use a job story and say "When I press on the brake I want to slow down so I can come to a safe stop."
If you want to learn more about job stories we have a great introduction here: www.mountaingoatsoftware.com/blog/job-stories-offer-a-viable-alternative-to-user-stories