How much time should a developer spend on investigating bugs/user stories for sizing in a sprint?
Currently we have 2 sizing sessions and a developer has time (time-boxed at 5min) to investigate and tell the team in the sizing session what needs to be done/looked at/remember etc.
So, how long should a developer spend on that investigation?
In Scrum, this type of work is considered Product Backlog Refinement. Per the Scrum Guide, it "usually consumes no more than 10% of the capacity of the Development Team", but this isn't a hard time box like other Scrum events.
There's also no guidance to how to use this time - I've seen cases where the entire team books time to review Product Backlog Items and investigate them together and other cases where individual members of the team take different Product Backlog Items and do sufficient work to understand them and be able to explain them to the rest of the Development Team.
I would count your sizing sessions against this 10% of capacity. But do consider that Product Backlog Refinement isn't considered an event in Scrum, like Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective. It doesn't necessarily need to involve a meeting, but I've found a set time to review the Product Backlog, get a high level overview, and then determine what (if any) further investigation is needed is helpful. This same meeting can be used to look at items that required investigation to get everyone back up to speed to be able to estimate.
So, how long should a developer spend on that investigation?
If the team can't estimate a user story—more canonically, a Product Backlog Item (PBI) in Scrum—with "close enough" accuracy within about 5 minutes during Sprint Planning or Backlog Refinement, the story either needs to be decomposed or replaced with a story spike.
If members of the Development Team need to go off and do discovery for a spike, you estimate the time and effort needed for the spike (usually less than two days, but I've seen Sprint-length story spikes in my professiona practice) and ensure that the spike is prioritized for the upcoming Sprint. Also make sure its estimate is part of the team's capacity planning for that Sprint.
Once the spike is completed, you would use what you've learned from the spike to decompose or estimate the story itself for acceptance into a future Sprint. As a general rule of thumb, it's unwise to have a spike and its dependent story within the same Sprint. There are exceptions for narrowly-scoped spikes, but don't put your Sprint Goal at risk by taking on work of unknown size or scope!
As mentioned above, an ideal spike is about the average size of a user story. In a typical two-week Sprint, the ideal time box for a spike is about one-half to two days in length. However, the spike should be as big as needed, but must never exceed the length of a single Sprint.
The point of a spike is to perform scoped learning. However, the scope should be just enough to make the stories or epics its related to estimable. Anything more than that, such as in-depth research or a product bake-off, really ought to be a set of PBIs in their own right.
Also, remember that story spikes aren't "free." They consume team capacity, and need to be tracked as work on the Product Backlog when they are known ahead of time, or created as extremely short time boxes on the Sprint Backlog if the need for a spike is uncovered for work-in-progress on a PBI within the current Sprint.
A big plus of a team sizing stories is that different people will have different perspectives on the problem and solution. Those need to be discussed to find the best option. One developer doing that work and presenting it sounds kind of self-defeating.
The team should have enough knowledge to size most if not all stories without extended preparation. If they need to "look things up" it's either too technical and detailed, or the product is not well understood.
If the team does not understand the product well enough, it certainly is important to get them up to speed, but there is no time frame. You will have to decide how fast you need the team to get to that level.
So from my personal experience, there should be no dedicated preparation and no presentation by a single person per story. Everybody should know the product well enough to estimate based on requirements and if not, at least somebody should be able to explain. If nobody in that meeting can do that spontaneously, you have a problem that cannot and should not be solved by changing that meeting, but rather by investing more time in getting to know the existing product.
Bugs are a different beast. The problem is, investigating is already the work to be done. Basically investigating would find the error and then somebody would be like "yeah, that's 0 points/SM/small, because I only need to commit my fix". But that's not really what needs to be estimated. The point is that you cannot estimate a bug-hunt properly, because you have no idea and getting the idea is what is supposed to be estimated. Personally, we just used two fixed sizes to say "this is unknown but sounds easy" (for example button text wrong) or "uh, this could be complicated" (for example report numbers not adding up). The estimation is always wrong, but over time it will be statistically correct, and I think that's the best you can get with bugs.
