In scrum, how do you track/estimate points when multiple tickets overlap their work?

Agile is all about responding to change. If you favour responding to change then you are likely to be doing the estimating relatively close to the time the work is to be done.

In this context, the situation in your question is far less of a problem.

Say, for example, we are estimating these stories a few days before work starts. A decision can be made about the order of A and B and hence deciding which story should incorporate C is easy. If change happens between the time when the estimates are made and the work starts then the team re-plans (possibly moving the C work to a different story).

Tangentially related is one final question: If we have stories (Most likely bugs) A and B that we believe are separate, and we bring A onto the sprint, finish it, and realise that B is actually completed as a result of doing A, what do we do with points?

Story points are a way of helping a team to decide on their capacity to get work done for future sprints. If both bug A and bug B have been done then the story points for both should be counted.

However, it would also make sense for the team to learn from what has happened. Perhaps if it is discussed in the team's retrospective they may work out how to better identify this situation in the future and so improve the team's capability at estimating.

It depends.

In my current role, we try to minimise the amount of effort we put into the Scrum process, and focus on actually building software. As a result, our estimates tend to be a bit rough. On that basis, we tend to include C in both estimates if and only if the overlap is relatively small. Although this messes up our estimates a bit, the error we introduce is small compared to the error we already tolerate. This might not be 'by the book' Scrum, but it works for us.

Again, in my current environment, the priorities of stories shift frequently (not ideal, but not something we can fix easily). As a result, if C is a large-ish story then including C in one of the other stories (A for example) is generally a mistake because it would make the other story (B) misleadingly small. This almost guarantees that the POs will ask us to do B first, as it appears to offer more value out compared to effort in. The exception is when A is for the current Sprint, and B is known to be for something later. In that case, we might break our own rule of thumb and combine C with A.

In all all other cases, we fall back on making another story for C. My team tends to avoid this, as our management tooling doesn't visualise dependencies very well. This is far from ideal, in that we allow our tooling to drive our method. This is something we plan to fix, and when we have done so this will become our default option, I think. In the mean time, we need to be pragmatic, and get the job done with the tools we have.

I see three options.

My preferred option, in this case, is to have stories A and B. The work for C would be denoted as something that needs to be done in both of them. If the team is estimating, then I would estimate both as if the other didn't exist, and the set of work C was part of both. This enables you to choose which one you do first without missing the estimate. Of course, it also means that one is overestimated, but it's also easier to spend extra time doing something valuable than underestimating and not reaching your goals.

A second option would be to split work C out into technical enablement work. However, this adds a dependency: C must be done before A or B. At the very least, C and A or B must be in the same iteration. It puts a lot more constraints on the team concerning how they order work, both in the backlog and in the iteration itself. I believe that dependencies should be reduced where possible and minimized where not.

However, the approach of splitting C away from both A and B would be viable if neither A nor B could fit into an iteration with C. One of the ideas is that each work item should be something that can be designed, implemented, tested, and delivered in an iteration. If that means splitting it out, it could be worth it even if it means adding a dependency.

I think the worst option would be to estimate C with one of A or B. It adds an invisible dependency. There's otherwise no dependency between A and B, yet if you choose the wrong one first, your scope of work will be incomplete and you could run into a case where you can't complete the work within the iteration.

It seems that you are considering certain things to be immutable. Like having to always split stories vertically, or that there shoudn't be dependencies like C, or that once allocated story points can't be changed. These are not immutable.

All the projects out there, all the products, all the features, and all the stories, will never fit entirely with all the good practices one is supposed to be following. Sometimes you just get a fly in the ointment, and that's that.

What is a good approach then? A good dose of pragmatism.

Right now you seem to be in some sort of analysis paralysis in which you don't procede because you try to figure out what the best way to do so is. Instead, just think what will be the reasonable thing to do next and do it. You are then in a new situation. Think what will be the next reasonable thing to do and do it... etc. You get the idea.

Going back to your questions, the reasonable thing to do looks like that of having a story for C. Estimate it and do it. Then have stories for A and B estimated by themselves with the assumption you already have C in place. If they all fit into one sprint then you are golden, if not, then that's that. There is no problem. Having just C in place adds value to the product, it just does not add value right now for the user. But it will once A and B are done. Don't think at value as absolute. C is valuable otherwise you wouldn't do it at all.

Then with your other example of working on something which in turn takes care of another item. If you don't need extra work on the second item, just change its points at zero because that reflects the reality of not doing any work to burn down its points. Then you can decide if you want to pull something else in the sprint in its place (as long as it does not negatively impact the sprint goal).

All of these things get resolved by the team working together and taking decisions together, in a pragmatic way, about what is the most reasonable thing to do next. And if you make mistakes, at least you'll have something to talk to and learn at the retrospective :)

It's a common problem when managing soft dependencies between stories. If A and B are small enough to fit in a single sprint then that's the most logical split. Avoid creating technical story for C if you can.

For estimation purposes it's up to the team. If there is a clear priority order then you can build the technical effort (C) into your estimate for the first story you intend to do and estimate the later stor(ies) as being smaller. Alternatively, if you aren't sure which will come first then you could average out the estimate across all of them and just accept that velocity will drop when you work on the first one and then pick up when you work on the others.

If A and B are both in the same sprint then it doesn't really matter, just allocate (A+B+C)/2 to both A and B.

Vertical Slicing is a Best Practice, Not a Framework Requirement

Your prerequisite tasks (by definition) must be prioritized over their dependencies, so a separate task or user story for C should be created to track it. The only reason this feels a little icky to you is that you're making at least one of the following implementation errors:

1. Allowing your tool (presumably a ticketing system like JIRA) to drive your process, rather than using tools that support your empirically-designed process.
2. Conflating the general guidance to deliver a vertical slice of functionality in each iteration for INVEST criteria.
3. Treating an ideal best practice (e.g. decomposing stories into thin vertical slices) as a framework requirement rather than focusing on coherent functions that deliver value for the iteration.

Scrum doesn't require "vertical slices." It's not mentioned even once in the Scrum Guide. Instead, Scrum requires a Sprint Goal that delivers a coherent function, which is an often-overlooked aspect of the framework. It's that central coherence that should ideally represent a vertical slice, not necessarily each of the various user stories or individual tasks needed to deliver it.

It should also be noted that Scrum only requires that Product Backlog Items should have "value" as an attribute. How value is defined is up to the Product Owner; its definition is not limited by the framework, and is most certainly not limited to being a full-stack, end-to-end slice.

By decomposing user stories into items that are small and independently testable (like your A, B, and C tickets), and ensuring that each Product Backlog Item selected during Sprint Planning is sized to fit within a single Sprint, you can then sequence the dependencies so that you can prioritize within or across Sprints as needed.

Combine the back-end work with one of the front-end tickets

Welcome to pm.stackexchange!

idea of vertically slicing the tickets

You are right that you should vertically slice the tickets because each story should deliver value to the users. If the back-end work is not done, there is no value.

Also, in more practical terms, when you combine the back-end work with the corresponding front-end work, you can test it end-to-end and be sure everything works well.

Bug question: If "you bring A onto the sprint, finish it, and realise that B is actually completed as a result of doing A" you close B and that is the end of the matter!