It helps to distinguish between stories and tasks

Introduction

Agile/Scrum teams using Jira often create a "story" for everything they work on (except bugs and improvements).
Tracking your work is not a bad practice, but not distinguishing between stories and tasks can be.

So what's the difference?

Stories contain changes that are visible to end-users.
(Most) tasks contain changes that not visible to end-users.

Examples

To make it a bit clearer, here are some examples of stories:

• create installer
• add login screen
• add "Cancel" button
• add application to OS startup

While not all changes are visual, they are all clearly visible to the end-user (ok, some users might be oblivious even to the most obvious graphical changes of an app, but that's a different story - pun intended!)

And here are some examples of tasks:

• refactor login screen code
• add documentation for IDE setup
• research how to support 10k concurrent connections
• integrate unit test framework
• add third-party library to project

All of these tasks, when finalized, will have no impact on end-users. They don't know or care about unit tests, refactoring or third-party libraries. With or without them, the application/product is the same to end-users.

Ok, so what's the real benefit of this "separation"?

It's testability.
In Scrum teams, the Definition of Ready should (ideally) contain a checkbox that says "is this testable by QA?".
Also, the Definition of Done, should (ideally) contain a checkbox that says "has it been tested by QA?".

All stories can be tested by QA! Why? Because "Stories contain changes that are visible to end-users".
Can tasks be tested by QA? Not really. At least most of them can't. Why? Because "(Most) tasks contain changes that not visible to end-users".

"refactor login screen code" - Other than running a set of regression tests to make sure nothing was broken, there's not much QA can do to verify this. But then again, this wouldn't mean that they are testing this task alone, would it?
"add documentation for IDE setup" - Sure, QA can look at the documentation and actually try to do what was written there, but I would hardly call that QA testing.
"research how to support 10k concurrent connections" - QA can ask developers what the result of their research was, but this would not be QA testing.
"integrate unit test framework" - Other than making sure everything still compiles ok, there's not much QA could do. But again, this isn't QA testing. Or QA's job, for that matter.
"add third-party library" - Again, QA cannot test this specifically. Best case, they could run a set of automated regression tests to check that nothing was broken.

Conclusion

While it's easy to consider everything as a "story", it might help to distinguish between stories and tasks sometimes.

Let me know your thoughts!