Dealing with stories/functionality that will spread across the entire lifetime of the project

Question

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

Answer 1

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).

Answer 2

TL;DR

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.

Answer 3

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.

Answer 4

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