Have you ever been in an agile estimation session that seems to drag on for hours? Where the team makes so little progress, you have to wonder why you're doing it? Isn't there a quicker way? Well, yes there is. But before we go there, let's first understand why your planning poker sessions are taking so long.
One reason lies in a situation I encountered just recently, with two different teams, and what I observed was that the discussions concerning each story took a lot longer than I expected. In fact, one team managed to estimate just 5 stories in two hours! Can you guess why? As an example, one story was about a facility to accept a monetary value, allocate it to one of a small number of 'pots' and perform a calculation before presenting a summary of the transaction. Not complicated, you might think. But the acceptance criteria, instead of listing how the Product Owner would test that the story was 'done', effectively defined the development steps - "system should fetch possible types", "upon clicking ok button...", "there should be an amount >0 entered...", "calculate the check total", etc
Now the problem becomes clear - these are not acceptance criteria. They are a detailed solution design.
In the estimation session I mentioned earlier, these detailed steps generated a lot of conversation around how they were to be implemented, about APIs and whether the click-through to the next screen was part of this story or the next one. The more detail in the story, the more discussion there was. And the longer it took to estimate.
If they had generated the requirements before considering the technical environment (admittedly difficult considering this was a platform replacement project), it would have been a lot easier to retain a user-centric view. At this stage, you're probably thinking that sure the team needs to know the technical detail before estimating the effort. Not at this level, no.
If you are estimating the effort or duration of an activity in absolute terms, then you need to understand the detail within that activity. But that's not what planning poker is. planning poker is intended to generate, as quickly as possible, a group understanding of the business/user needs and estimate the size of each relative to each other. This does not require loads of technical detail. It is sufficient to understand that the story comprises (for example) a browser page with an input field, associated validation and a click-through button; an api will provide background data for validation.
"Low complexity web page, API call and some validation logic - that's a 5."
That's about as much detail as you need. Apart from shortening the time taken up by estimation, it also ensures that the stories are Negotiable, which assuming you have an engaged Product Owner, is essential to ensuring the right outcome.