ISSUE TRACKING AND ASSUMPTIONS
Most all teams (working proffesionally) have some issue tracking implemented.
They do not track "lines of code out the door" as others have commented on, but the progress on the task itself.
You (and your team) identify the issue and assume how long it's going to take you
The issue could be a bug, refactoring, learning something new, writing documentation or tests. Not all of those produce code or new features.
The time is including self-learning and everything else.
Unless you're experienced with what you're working on, these assumed times change, we try to give ourselves as much time as reasonable (i.e. assume how long it§s going to take and double that).
It's not always possible to have that time and at that point, you either scrap it, change the requirements, move it to some other time (ages and ages hence :)) or pull an allnighter and CRUNCH.
Correct identification of how long something is going to take is a very important skill learned by getting it wrong and learning from it.
Don't be afraid to change the assumption as you learn of new problems/constraints and don't forget to properly communicate with others around you who have an interest in them.
You then work on it and update the issue as needed (update the task in JIRA, tell others during a stand-up, tell your manager on a weekly meeting,...). You COMMUNICATE with people around you as needed.
People who are used to this know that as a junior (assumption on my part since you're asking this) you don't have the knowledge to call the time it's going to take. Even seniors don't know everything beforehand, they do preliminary checks and update/create the assumptions after that.
Tasks are not about how much code you've written. There are a lot of internal tasks (setting up an environment, trying to reproduce a bug, learning something new in order to implement something, refactoring, getting rid of technological debt, writing tests, writing documentation) where you don't write much code at all and instead sink your time to just trying to do something seemingly unproductive.