What are some methods of addressing user stories that are deemed to be too large by the development team?

Remember that the Product Owner does not traditionally have the authority to decide exactly how a story is broken down. Product backlog refinement is a collaborative team-owned process that relies on both technical and user-driven considerations. It is best to use inclusive language that demonstrates a team-based approach.

The teams I have worked with use three main methods of addressing stories that are too large. First, we see if there is an opportunity to break the stories down into smaller stories. If so, we try to break the stories down so that each of them could stand on their own and add value in the event they are not all able to be released together.

Secondly, if the group of stories is large enough, we relate them together with an Epic. This allows us to track the progress of the overall development effort in addition to the status of individual stories.

Thirdly, I work with the team to determine if adding a spike story would be beneficial. We add one in the event developing a proof of concept or allowing time for research would reduce risk and the size of the story in question.