I'm trying to determine how I would deal with a story/epic that appears to potentially spread across every sprint.

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.

* Now that story might not be perfect but I hope it illustrates the kind of story I'm talking about.

My query is how you might go about dealing with this in agile. My thoughts were:

  1. Implement this as an architectural story in that you do the framework for making this happen but each specific instance is incorporated into other stories that needs specific help.
  2. Identify all places where help will be required and make that tasks/sub stories. However what if you don't know where these places will be exactly?
  3. This shouldn't be a story at all? In this case, how would we handle it better.
  4. None of these points and something entirely different as the story is written poorly
  • 1
    consider picking one of the answers as the one that solves your problem or let us know if you need additional help. Commented Sep 3, 2014 at 9:23

4 Answers 4


There's two parts I see in your story:

  1. You need infrastructure for your help system. That's a story on its own and has a defined end (though the required effort depends on how fancy you want your help infrastructure to be ;)).
  2. You need create help information, whenever you add some "data inputs". That's not a story, because it never ends. It's more like a quality that applies to every story that changes ui. Therefore, you could either manage it as a quality, make it an acceptance criterion, or make it part for your Definition of Done, which requires Devs to check it before they can close a story (you want to make sure it's not forgotten in 3 month from now).
  • 1
    Wouldn't it be part of the acceptance criteria for a story? I wouldn't want to make this part of my definition of done as it will not apply across every story.
    – dreza
    Commented Sep 4, 2014 at 20:49
  • @dreza I see your point. I think acceptance criteria and qualities are rather similar concepts... Challenge is, you need to ensure that you never forget to add this criterion to any story that needs it. In the DoD you can't forget it. Extended my answer. Thanks!
    – Sven Amann
    Commented Sep 5, 2014 at 7:32


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:

  1. 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.
  2. 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.

  • Very good answer, consider pointing out that stories should be small AND deliver some business value (if someone won't go into your invest link they might miss it). I've seen several times "stories" that should be in fact tasks as they weren't independent and weren't bringing business value by themselves. Commented Sep 3, 2014 at 9:25

That is not a proper story, that is just a guideline on how to write good user interfaces. It must be easy to check if a story is implemented, otherwise the story is useless. If stories like that were okay we would only ever need this one:

As a user using this application, I would like the application to fill my needs, be free of bugs and be easy to use.

Acceptable stories that are similar to the yours would be:

As a user filling a date field, I would like the application to give show which date format it wants.

As a user filling a number field, I would like the application to give show which format the number should be in.

As a user filling a field, I would like to see an example of valid input for that field to make it easier to understand what format the field should be in.

These are concrete and easy to verify. If you add more number or date fields in the future then we just apply the same functionality to those fields as well. However if we get a new kind of fields we will need a new user story.

In cases where you get unworkable user stories it is important to reject them and explain why. A user story like that only hurts the development process and gives the testers an endless amount of things to complain about since the story can't ever be completed.

  • Cheers Johan for your comments. In your view could it be considered an Epic then?
    – dreza
    Commented Sep 7, 2014 at 9:38
  • This is not an epic user story. Epic user stories can still be finished even if it takes a lot of time. This story however can never be finished since there are too many questions left unanswered: Which data fields are the user talking about? What information do the user want to see? What assistance would the user find useful? Without answering these questions you can't finish the story. In this case the developer would have to come up with answers himself for every field you got now and every field that will ever be implemented.
    – Johan
    Commented Sep 7, 2014 at 10:31
  • If you need to explain it to someone you can say this: A user story should answer a question the developers might have. This user story leaves too many questions unanswered for it to help anyone. For example, would any kind of helpful text be good enough? If not then you need to describe that more properly. If it is impossible to give a good description on how it would look for all fields then you need to split this story into one story for each case.
    – Johan
    Commented Sep 7, 2014 at 10:50

I would recommend looking at @Sven part of answer on Definition of Done. If you haven't done so yet, get together with the team and Product Owner and agree on Definition of Done for this particular product/project.

See how Scrum defines DoD: https://www.scrum.org/Resources/Scrum-Glossary/Definition-of-Done

  • Sure, I understand this definition of done. I'm wondering what would be recommended in this situation however. Cheers
    – dreza
    Commented Sep 1, 2014 at 20:13
  • @dreza this is what I did successfully with many teams. Commented Sep 2, 2014 at 13:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.