Your stories aren't granular enough. You haven't identified anything truly actionable in your story, and it's extremely unclear how the feature will actually benefit the value consumer (in this case, "a user").
Make Your Stories More Granular
You gave this as your example story/epic:
As a user I wish to have see help information against data inputs so that I can see a description and get assistance for inputting the correct data values.
This is overly broad, not granular enough, and doesn't lend itself well to acceptance testing of any sort. In particular, the way it's written seems to violate most of the INVEST criteria.
Assuming that I understand what you're really trying to do here, you probably have a set of input fields that need some sort of help text and/or validation. You need to define stories that deliver measurable value and provide testable criteria for these input fields. For example, a typical suite of related stories might look like:
- As a user,
I want to see a sample entry in the foo widget box
so that I have an example of what I should type into the box.
- As a database administrator,
I want the foo widget box to validate the correctness of its data
so that I don't have to perform data cleansing activities later to remove bar entries from the foo table.
Each story should be independent and testable. How many of these stories you will actually need will depend a great deal on the skill level and process maturity of your development team. While I can certainly imagine ways to write a single story that captures the intent of the whole epic, I imagine that your team's process would benefit immensely from the clarity that comes only from decomposing this set of stories into one such story pair per unit of work.
In my personal experience, it's usually better to make the work visible by being too granular than it is to commit to stories that are too big to deliver (especially in a testable way) within a single iteration. Fine-tuning story granularity is an ongoing process, and is a normal part of any team's inspect-and-adapt process.
Keep your stories small. Only go up a size when you can do so without violating the INVEST criteria.