Struggling with giving estimations

Hi P. Ross,

Having this hesitancy is common. At this junction (Sprint Planning), I would try to reassure the Dev Team that what they are offering is a "best guess"

I wold also use the "....HOW and therefore I can't estimate..." to foster a discussion amongst the members of the Dev Team. Allow them to know that more information may emerge on the HOW during the creation of the plan (e.g. task breakdown) during the planning, or the days ahead. This should also be welcomed (hopefully.)

At the end of the Sprint, the SM should hopefully raise this at the Retrospective, unless there's going to be a dialogue on this, naturally. The Dev team can compare what transpired Vs. what was forcasted and make adjustments as they think appropriate.

I would hope that as more information emerges as people learn more on the legacy systems, the estimations become easier. This has been witnessed by one of our teams as more information on the project emerged.

At a subsequent Sprint, perhaps one could look at a previously completed PBI and compare to the one in discussion? E.g. "I think this is a 5 because its similar to what we did here in Sprint X..."

Another tip would be to check whether there is a SME available for the legacy system or domain knowledge who can talk about this. Perhaps a backlog item capturing KT...?

Another tip is to use an architectural spike -- i.e. there may not necessarily be a piece of functionality built, but an exploratory exercise to be completed. If the Team wants to slice the PBI's even smaller, or something else emerges, do allow for this.
.
.
.
If I could take a step back and ask -- are there refinement meetings taking place? This may be a junction where the team can learn more or take a guess at what may be needed with the HOW. However, here, again, I would try to reassure them its just an estimate.

+1 to Nitin's answer.

Are you doing regular product backlog refinement? I coach most teams to start out with 1-2 hours per week, though the Scrum maximum time-box for that activity is 10% of each sprint for the Dev Team, so it may take longer than the 1-2 hours per week.

Do your devs have access to the code and other arch docs? Access to SME's on the relevant code/arch components? If so, maybe invite them to refinement meetings?

I can't explain this, but I've found that while people find abstract sizing hard, they are pretty good at sorting and ordering. It's odd because in real terms it amounts to the same thing.

So you could try doing a team sort of the cards instead of planning poker. Use T Shirt Sizes instead of numbers. Gather the team round a table, upon which you have horizontally lined up a series of sticky notes labeled XS, S, M, L, XL, and XXL. Put the stack of PBI's on the table as index cards. You can arbitrarily place the first one under M to provide an initial reference. Now the team sort the remaining cards in terms if being smaller or larger than each other or the same size. If the cards are bunching up towards one end, normalize the distribution by moving them all upwards or downwards so that M represents the average.

Problems can include assertive team members dominating more reticent ones, but you can tackle this by inviting each team member to then move a card up or down by one position. Do this 4 or 5 times and you can consider it done.

Once the cards have been sorted, points can be mapped to the cards. 1, 2, 3, 5, 8, and 13 are reasonable and will provide a decent first cut.

A lot of the projects I've worked on have been ones where they were just black boxes and I've had the same issues you described with regards to estimation.

I used to struggle a lot when I followed waterfall and was asked to estimate in hours/days about a particular feature I knew nothing about. After all predictive Project Management assumes that the Project Manager or Technical Lead is a visionary super power.

However with Scrum I started relaxing a bit since the main idea behind Scrum is expecting and embracing change. Even the Sprint goal offers a certain level of flexibility. I soon realized that a T-Shirt estimate is more than enough for the first Sprint planning meeting with a commitment to delve and get more information in the coming days about something I was working on.
Many a time on the first day of the Sprint meeting my tasks in the Spring backlog were non-existent but we used to have detailed technical discussions after every Scrum meeting and this sometimes used to include Subject Matter experts who used to spare time to answer our queries. All of us were expected to do a lot of research ourselves and now with the surplus of information around on the Web it was just a matter of time before all of us knew enough to add more well defined tasks to the Sprint backlog.

In conclusion I can say its perfectly fine to be completely blank on the first day but then if you have a plan to dispel the darkness then you are on the right track.
Remember that negotiation with the Product Owner is always an option when the team discovers it is tying to reach an unattainable sprint goal. All that matters is you have an argument based on facts and experience gained over the sprint and not just guesses.