Backlog grooming items planning

Question

In a Scrum project if the team is from 4 developers, the sprint is two weeks long, Team Velocity is 40 SP/Sprint and the Focus Factor is 0.6. During the Backlog Grooming meeting, user stories with how many story points should be split into technical tasks?

Answer 1

Some of this information is extraneous. When figuring out how much of the backlog to have refined, I've never really considered the team size, Sprint length, or "focus factor" (I'm not even sure what that means in your context). The only thing that I look at is how much of the Product Backlog has been refined.

Personally, I favor having the top of the Product Backlog refined to the point where the work is likely to fit into about 3 Sprints.

Unless something new is added or there are major changes in the environment, the top of the Product Backlog is the work that is most likely to come up for development in the near future. Ideally, the Product Owner is making sure that the order is reflecting factors such as value, priority, and dependencies on a near-continuous basis. A big surprise at a Sprint Review, for example, should be rare to uncommon for most teams. Even if things shuffle around, the team should be able to take a lot of refined work into a Sprint and do a little bit of refinement after the Sprint Review on any feedback that comes out of that event.

This approach also strikes a balance between having enough work refined to make most Sprint Planning events very straightforward while also not planning too far into the future and wasting time thinking about work that may change before you get there.

In the specific example in the question, I'd want the first 100-150 story points worth of work to be refined and ready for the next Sprint.

I will add, though, that different environments may have different good ranges. If your environment is highly stable and more well-understood, you may be able to get away with refining a little more of your Product Backlog. I wouldn't want to plan more than 6 Sprints of work ahead, though, even in these more stable environments. Other environments may be much more unstable and ambiguous. Refining 1 or 2 Sprints may be more realistic to make sure you aren't wasting time refining the wrong stuff. You may have to take on work with more ambiguities in it at Sprint Planning in these environments.

Answer 2

I don't think there is a magical answer for this, so most replies will most likely be approaches to an "optimal" solution.

Here is mine, if what you wish to know is "when" to split a user story in two so that the team can work on it without putting at risk the amount of work they can cover per sprint, then I suggest you take two possible conditions into account:

1. If the product owner has a good understanding of the product from the technical perspective, chances are he/she already has some idea on where to split a user story if it is too big. However this is not exactly a duty of such role, and it would make more sense if splitting it in half is aligned with the vision of the product and the goals around it.

2. The scrum team can choose: the best way in my opinion is to hear what the team has to say, if they consider that the story may be too long to cover on a single sprint, it might be better to split it. Consider that this is not necessarily related to the amount of story points it has, because some stories may weight 1 or 2 SP but the risk around them may bee too high to consider adding more work to it, so perhaps it is convenient to simplify it as much as possible.

Finally, it is widely said that story points should not be compared from team to team, as they are a result of the specific mindset and subjectivity of a team, and not a golden rule to apply everywhere. That is why one team can estimate with points using Fibonacci while others may do it with T-shirt sizes, and both approaches are neither correct nor wrong.

Answer 3

Don't Split Stories into Tasks During Refinement

During the Backlog Grooming (sic) meeting, user stories with how many story points should be split into technical tasks?

The canonical answer is "none," because:

1. The 2020 Scrum Guide doesn't say anything about user stories or story points. They're not part of the framework.
2. Backlog Refinement (formerly called "Backlog Grooming") is focused on refining the Product Backlog rather than the Sprint Backlog. Therefore, from a framework perspective, anything too detailed to be a Product Backlog item (PBI) is a step too far.

Notes and Caveats

1. This is obviously a test question, so the only correct answer is the one your instructor told you will get marked as "correct."
2. Earlier versions of the Scrum Guide were more prescriptive, so if they're still calling it "Backlog Grooming" your mileage may vary somewhat.
3. Story points are a technique; they are not defined or mandated by the Scrum framework.
4. Stories or PBI's are about what. Technical tasks are about how. Don't confuse the two!
5. You should split stories or Product Backlog items into smaller ones anytime they are in near-term scope and are too large to comfortably fit within a single Sprint.