• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
Bartenders:
  • Frits Walraven
  • fred rosenberger
  • salvin francis

right way to include a user story in sprint which is bigger than what can be done in a sprint

 
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Suppose we know that in our team historically we have been completing a 5 story point user story in full sprint. Now while estimating we give 8 user points to a story and thus know it would not fit in the sprint.  One obvious idea is to break the user story and remove one or two of the acceptance criterias from the scope and move that to another story. Is this the right way or there are any other ways ?
Thanks .
 
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Invent a machine that slows down time so you can fit 8 points of work in that sprint. If you don't have that technology, then splitting the story up into smaller chunks is the next best thing.
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks. For splitting the story, is dropping some of the acceptance criterias the only way?

Story points to a user story should be given based on the complexity. But while giving story points  complexity can be compared when length of the stories is the same. A lengthy story with several acceptance criterias is bound to take more time even if it's complexity is not high. How to account for this while giving story points ?
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:Thanks. For splitting the story, is dropping some of the acceptance criterias the only way?


Please explain what you mean by dropping acceptance criteria—seems to me there are a few different ways that could be interpreted. Give us some concrete examples to illustrate what you mean.
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Read through this article: https://techbeacon.com/app-dev-testing/practical-guide-user-story-splitting-agile-teams

See if "split by dropping acceptance criteria" is one of the recommended approaches to splitting stories.
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:
Please explain what you mean by dropping acceptance criteria—seems to me there are a few different ways that could be interpreted. Give us some concrete examples to illustrate what you mean.



For example a user story is there  for shopping cart. Acceptance criteria 1 says user should be able to add elements to the cart. Acceptance criteria 2 says user should be able to remove element from the cart. If this user story cannot be fitted in one sprint, then the second criteria can be removed from scope and put into another story which would be done in another sprint .
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
That's a different if not strange way of looking at it. I'd argue that what you're really doing is splitting by capabilities offered, which is one of the story-splitting techniques described in the article I cited. So, rather than saying you're splitting by acceptance criteria, you're actually splitting by the capability to add items to your cart as one story and the capability to remove items from your cart as the second story.
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes. Splitting by feature and this seems to be the most common way of fitting a bigger story in sprint.
 
Marshal
Posts: 8011
563
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:Splitting by feature and this seems to be the most common way of fitting a bigger story in sprint.


After splitting you won't fit bigger story to a sprint. You'll fit as much as you can handle in a sprint. In different words, the story of the size you can chew.

But what you actually said, at least how I understood what you said.

1. There is a big story let's call it X, and that can not fit to a sprint
2. But if we split that story to an x and y, which are smaller stories, than we can fit to a sprint

No - in the end you get the same amount of work needed to be done, however, there is a benefit in second approach, that two people potentially can work in parallel on the same stuff just implementing different stories/features.
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:

2. But if we split that story to an x and y, which are smaller stories, than we can fit to a sprint

No - in the end you get the same amount of work needed to be done,



Yes. In that case if that can still be not fitted into Sprint then what should be done ?
 
Liutauras Vilda
Marshal
Posts: 8011
563
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:In that case if that can still be not fitted into Sprint then what should be done?


Same
 
Liutauras Vilda
Marshal
Posts: 8011
563
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
On the other hand, not sure what is the length is of your sprints, but ours are 2 weeks. In those two weeks 1 developer can do quite a bit. I understand that "quite a bit" is not very concrete, but I hope you understand what I mean. So I can't imagine about what kind of monstrosity we are talking about when you say "Can't be fitted to a sprint".
 
Liutauras Vilda
Marshal
Posts: 8011
563
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
There are many ways how you can story point your tasks. One way for example could be, 1 point is half day, 2 points is a full day - so create such stories which one developer could do in one day. You could follow Fibonacci sequence for instance 1, 2, 3, 5. So 5 pointer would be roughly 2.5-3 days.

So if we say that sprint is 2 weeks, then there are 10 days, ok, let's say 8 for actual development as there are meetings et cetera, so 1 developer in that way could aim to accomplish 16 story points. What I'm getting at - developer should be able to do something during the day, so I can't imagine what kind of story you have in mind, that it couldn't fit to a sprint.

You don't create stories which say "build the system". That might be an Epic which at the end would be a built and working system (more likely just part of it). But that would spread across few/several sprints.

 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:There are many ways how you can story point your tasks. One way for example could be, 1 point is half day, 2 points is a full day - so create such stories which one developer could do in one day. You could follow Fibonacci sequence for instance 1, 2, 3, 5. So 5 pointer would be roughly 2.5-3 days.


This is the reason many people have given up on user story points. One person, in particular: https://ronjeffries.com/articles/019-01ff/story-points/Index.html has mixed opinions about their utility. In my experience, they're more trouble than they're worth and as a coach, I'd rather not introduce points to teams who are more likely than not to misuse them.

Read the top results for "should you equate story points with time?"
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Monica Shiralkar wrote:Yes. In that case if that can still be not fitted into Sprint then what should be done ?


Keep splitting until the work is small enough to fit. Not sure why this is such a hard concept to understand.

If I had a cake and a box that was much smaller than the cake, and someone asked me "How do I fit this cake into this box?" the answer would be, of course, "You can't! But try slicing the cake in half and see if it fits."

Then that person comes back and says "I sliced it in half and it still doesn't fit in the box. What should I do now?"

In the real world I would probably turn to that person with a "Are you #$%^& kidding me?" look on my face. The answer is the same: "Keep slicing until you have something that does fit in the box!"
 
Liutauras Vilda
Marshal
Posts: 8011
563
Mac OS X VI Editor BSD Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:This is the reason many people have given up on user story points.


I don't want to interrupt this thread, but I recognise what you are saying. In the past few years worked in a couple of different teams and projects, and the way teams worked differed. Our current team is fairly new, so we are still looking for a better ways, and unfortunately we do not have coaches like yourself who'd have a recognized expertise in that. But as long as we deliver product on agreed timelines, we do not reproach to ourselves much, but are very open to address the things if we see that we drop the ball more often than not.

Despite that, I'm keen to raise this point to the team.
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The misuse of points often comes down to the misuse of estimates. Estimates are a way of communicating to those downstream to your work when they can expect things to come their way so they can be ready to handle it. They in turn can communicate to those further downstream when to expect things to reach them. That's why the language has changed, at least with those who know better, to "forecast" instead of "commitment" to give a sense of it being like getting ready for a coming storm rather than a coming train. A storm is far less predictable than a train. Predictability of work can vary, sometimes like a storm when there are too many variables at play or maybe more consistently like a train when the scope of work is better understood and the factors that make it variable are known and within the team's control. If there's a variance between the forecast and reality, then those who will be affected, if given ample time, can adjust their plans accordingly.

The problem is many teams misuse estimates and treat them like commitments. When you do that, blame goes back upstream and the developers are made to feel guilty about not completing their work "on time" when in fact, they just were not able to complete the work as they initially thought they could. There could be many reasons behind this but it's really up to those downstream whose expectations were not met to adjust their plans accordingly. On agile teams, it's understood and clearly communicated what the chances of there being variances to the schedule are and all work is planned accordingly. Pseudo-Agile teams will try to make "better estimates" in order to "meet commitments" whereas truly agile teams will commit to being more predictable/consistent and more transparent so that when the inevitable variances occur, they can communicate that as soon as possible so those downstream can adapt their plans accordingly.
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Liutauras Vilda wrote:But as long as we deliver product on agreed timelines, we do not reproach to ourselves much, but are very open to address the things if we see that we drop the ball more often than not.


This is the part I mentioned where the development team is made to feel like they let everybody down somehow. Software development is not an exact science. Even simple problems have many ways to solve them, how much more for problems that are not so simple and have aspects that you can only discover as you try to implement a solution. It's not that you've "dropped the ball"—it's that the ball is in constant motion and keeps rolling around. It's a moving target so you should expect to miss once in a while or maybe even more often than not.

This is why you want to slice stories down to really small and simple chunks. If you reduce the scope, you also tend to reduce the number of variables you're dealing with. That helps you become more predictable. Agility allows you to be predictable and iterate rapidly so that even though you are delivering smaller chunks of value, you're doing so more often. That's why the planning window for Agile teams is anywhere from a few days to a couple of months in the future. The further out the plans go, the more uncertainty you'll have in them.

See the Cone of Uncertainty and get your stakeholders to agree to plan accordingly.
 
Junilu Lacar
Marshal
Posts: 16440
272
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
One thing I often say is this: "We're software developers, we're not psychics."

We can't predict the future but we can let those who are depending on our work know as soon as possible if at any time we think that our plans are going to change. The smaller those changes are, the smaller the impact. The sooner we can inform others of potential change in our plans, the better anyone who is affected can adapt their own plans in response to those changes.

Or to put it differently: "Change happens; deal with it."
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
When I meant some story would take more than 1 sprint, I meant
overall time taken for coding for the features, creating test data to run, unit testing, deploying to dev, test environments, could be more in case of some particular story. But yes if only say minimal number of features are taken then should be fine.
 
Monica Shiralkar
Ranch Hand
Posts: 2459
13
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Junilu Lacar wrote:
Keep splitting until the work is small enough to fit. Not sure why this is such a hard concept to understand.
"


Thanks
 
All of life is a contant education - Eleanor Roosevelt. Tiny ad:
Thread Boost feature
https://coderanch.com/t/674455/Thread-Boost-feature
reply
    Bookmark Topic Watch Topic
  • New Topic