Stories – How much granularity is needed ? (discussion on the Product Owner’s Helpdesk)


Stories – How much granularity is needed ?

I have some stories that can be complex and cannot be added to the sprint because of that- more than 13 story points-, it this case I use to split the stories in two, three or even more stories that can be measured, however this stories can become dependent or worse…not potentially shippable. So my question is: Is fair to sacrifice dependency for granularity?

2 months ago


Pierre E. NEIS ,csp

Pierre E. NEIS ,csp • Hi Fiorella,

This is a bloody question. I like it because the answer is almost « it depends ».

Orthodoxy tell us that only the team commits. So if the DEV team take the story then it’s ok.
If the PO pushes the story then we have a problem. Idem if the sprint backlog building is only based on velocity like  » we need to keep our 10″.
The best answer should be: if it’s feasible then it’s ok.

Dependency increase the risk of undone and produce tech debt. This can hardly impact the release plan and a consensus business/dev need to be taken. TechDeb decrease velocity and harm time to market.
What to do? You can use Scott Downey’s rapid scrum approach where you filter the story according DEEP. items or stories are all ready before start:
– high dependency = high risk = > reduce risk till ready to start

2 months ago2

Anders Larsson • This is a tricky question. One problem that could occur when breaking down stories to fit in sprints is that these might no longer gain any business value. In cases I’ve experienced the client doesn’t really value any release of done stories until the whole epic is done for a lot of the functionality. There are of course in most cases dependencies between stories within epics. One idea is to aim for bug fixes and independent stories within ordinary release rythm and longer cycles for the larger epics. As a PO it will be important to also prioritise stories that won’t be released in the « next Sprint ». I believe the breakdowns are still valid to measure velocity.

2 months ago• Like1

Bruno Borghi • In my experience, it depends how one splits the story. Splitting stories along acceptance criteria is often a good way to avoid dependancies. When one introduces technical stories to split a story, it increases dependancies and backlog complexity.

2 months ago• Like2

Fiorella Velarde Esenarro • Thanks all four answers! As you mention it depends and during the sprints we are gaining experience! My team is just staring and hopefully until the fourth sprint we will really measure our velocity and start adding more business value to our product. Thanks again for your tips and comments!

2 months ago• Like

Ander Fernandez Telleria • I have had this problem before, and as it has been said, it depends:

First: Does the user story comply with the INVEST approach? You can think here that it is not small, but the next question will point you into the right direction: Do the stories that result of splitting the big one comply with the INVEST approach? If the answer is no, because they are not independent, then, my first idea would be not to split it.

Second: What’s your team velocity? We all know that Story Point is a very variable magnitude, so for me, it does not mean much the fact that it has 13 SP. If you have a velocity of more than 30/35, I would go for it in one iteration. It is not a small story, but is not big enough to have the need of splitting it. There are more than 22 SP left of work to do, so the team members not working on this user story won’t be stuck with nothing to do.

Usually, when splitting user stories into two or three, their overall number of story points increase, as all of them need to comply with the definition of done. That can have an impact on your story map/release plan.

Good luck!

1 month ago• Like1

Geoffrey Etwein • Agree with Ander,

Try to respect the INVEST approach.
Reminder :
be Independent
be Negotiable
be Valuable
be Estimable
be Small
have Tests (acceptance criteria)

The parts that interest you are :
– Independent because most of the time when they are not we try also to estimate dependencies
– Estimable because if it’s not it will not be useful for the project and most of all it’s certainly to big
– Small … it’s always easier to estimate and to understood

Then after few sprint you will know what kind of details your team is waiting for.

1 month ago• Like1

Richard Thomson • Particulary with Application development i find that you often need to split a single business requirement into multiple stories, thus scarificing the dependency for granularity. As Anders states, In these cases the customer doesn’t get the value until the whole epic/functionality is delivered.

I try to target the average size of a story to be about 3-4 days duration (including dev/test/doc), so a story the comprises up to half a dozen half to full day tasks. Each story needs to comply with the definition of done, so is in theory potentially shippable.

1 month ago• Like1

Charles Bradley • It’s really important to have a potentially shippable increment at the end of the Sprint, so it’s hard for me or anyone else to give you advice not to do so. Having said that, a large story that is unshippable at the end of the sprint is not that much different than a few more granular stories that aren’t terribly shippable at the end of a sprint. Try very very hard to split the story so that it is shippable. You will sometimes have to use your imagination a little. « Shippable » mean’s it’s usable by a customer, and has the quality that all increments have — no messy or undone work. Although preferable, « Shippable » does not have to mean that « it makes business sense for us to ship this. »

You might find value in these splitting patterns from Richard Lawrence:

Hope this helps!

Charles Bradley
Scrum Coach-in-Chief

1 month ago• Like1

Fiorella Velarde Esenarro • Hi everyone! after some sprints and all your advises, my teams are getting more expertise. Thinking always in the INVEST approach the stories are becoming smalls and without dependencies. however as you said, in some cases the user will see value only when the epic is completed with should include security or performance aspects that are not easily identified at the beginning.

Thanks all for your comments!

Cory Bryan • I agree with the INVEST suggestions and really Ander’s 2nd point. It depends on the velocity of the team.

I would say as long as a single story it not over 70-80% of a teams velocity then it’s likely ok, whatever size the story is, it’s relative to their velocity.

If a team with a velocity of ~13 has a 8 point story, i would be ok with them taking on that story. If they had a velocity of ~11 then that same 8 point story is likely too large and needs to be further refined.

It’s a fine line but it really depends on the PO working with the team to make sure it’s understood and they are willing to commit to the work.

11 days ago• Like

Danielle Downs • The disadvantages I’ve recently found with too much granularity can be:

a) you spend a lot of time breaking stories down before starting work. In my experience, developers often don’t discover some of the hidden complexities (that could in fact render their original estimates futile!) until they get stuck in to the code. This can make it a waste of time and doesn’t necessarily make estimates any more accurate.

b) a story may be sized as a 13 but, when you break it up, each sub-story usually ends up being at least a 2 or 3. This means that the sum of the parts can often end up being greater than the whole; not necessarily because the work is more complex when broken down in more detail, but because teams are reluctant to estimate any story as a 1, as that is often something tiny like a text change (arguably a task and not a story!).

The question then is, what is « too much » granularity? I too use the INVEST acronym and find it pretty effective but I guess I am probably more flexible around the definition of ‘Indpendent’, which means stories can be sized in slightly more granularity than the whole minimum marketable feature set (MMFS) or minimum viable product (MVP).

What I mean by that is that sometimes, although it may be *possible* to deploy a feature to live, it wouldn’t be desirable to do so until other features are complete. E.g. if a feature only deals with one use case but others need to be handled to provide a good user experience, I don’t see the harm in treating each feature as an individual story, even though it may not, strictly speaking, be shippable entirely independent of other stories. On the other hand, if something sounds like a tech task, it probably is and it shouldn’t be treated as a story just for the sake of it. My main criteria, as a PO, is « will this story give me something I can see and sign off on (at least for internal deployment) when it’s done? ».

As a really general rule, if it’s larger than a week’s worth of work, it’s probably too big and needs to be broken down more.

My team has recently experimented with sizing « Epics » (features) in a range of weeks (e.g. 4-5) and then breaking them down into stories with points [min. 3, max. 8 so far] as they come to them on the backlog. so they’re estimating at most 4 weeks’ work in advance. Some epics have needed to be broken down into 3 or 4 stories but others haven’t needed breaking down at all (~ 1 week’s work).

The benefit we’ve observed of this approach is that you don’t start breaking the next epic down until you’ve at least started work on the last, so you can use the knowledge gained from each to usefully inform the estimate for the next. We’ve just finished the first epic that the team sized this way, which they initially sized at 4-5 weeks and it took 4 weeks 2 days, so that’s pretty close!

Previously, when they were breaking stories down into far more granular detail (2-3 pts), a lot further in advance, the total estimate for what we now consider an « epic » came out very large and was pretty inaccurate because the team either needed to make a lot of assumptions or spend a lot of time doing « spikes » to investigate, which actually delayed them starting the work!

Hope this helps!

10 days ago• Like1

Daniel Ceillan • Hi!

Large stories destroy the productivity, and generates risk facing the end of sprint.

Too small stories generates a lot of management effort, not only for the managers, but the Team too.

In a normal sprint of two weeks, I found that the stories should be done in 2 or 3 days. In a 30 points sprint, it means that no one story should be greater than 5 points.

Kind Regards.

7 days ago• Like

Jon Innes • My suggestion is that if during planning poker the story cannot be estimated by everyone on the team consistently, then you need to refine the story to be more granular.

Make sure the team members committing understand the story and can break it into tasks that can be completed during your sprint, whatever length that is. If that’s impossible then it’s too big.

Votre commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:


Vous commentez à l’aide de votre compte Déconnexion /  Changer )

Photo Google

Vous commentez à l’aide de votre compte Google. Déconnexion /  Changer )

Image Twitter

Vous commentez à l’aide de votre compte Twitter. Déconnexion /  Changer )

Photo Facebook

Vous commentez à l’aide de votre compte Facebook. Déconnexion /  Changer )

Connexion à %s