- This is what I do in my company:
i. Business requirements gathered from manager/product owner (PO) with businesss owner / stakeholders.
ii. PO and developers list down all the features that are needed to implement, from business scopes into features.
iii. Discussion to put high/medium/low priorities for v1, v1,1, v1,2 and so on (Google Minimum Viable Product (MVP)), agreed by business owner.
iv. Product owner/manager/developers and designer to come out wireframes (usually sketches) with those features discusssed earlier.
v. Confirmed wireframe by product owner and developers with stakeholders, the designer comes out final UI.
vi. Create stories, from there you plan how long each stories. If the feature is huge, make it as Epic, split into smaller stories, and plan the time for implementation (based on the developer who is going to do, NOT your manager to decide your implementation time). If you afraid to ask for more, and if you can't finish the task on time, that's your problem. Always be honest and frank to everyone, that's your team, they won't bite. If you fail, everyone fails. So if you finish earlier, pick new stories inside Backlog, and plan your estimation better in next sprint. You can ask for some "buffer" time to do research on certain features which is unclear in implementation for stories estimation, before implementation is officially started.
Log ONLY your working hours on that stories. Never log your lunch time (of course!). My previous company was doing "realistic" and "honest" Agile, putting realistic estimation of 6 hours/day for developers (admit that devs as human beings are using the rest 2 hours to watch cats videos, drink water, toileting, flirting, chit-chat, slacking etc).
Refer to 2. You should plan your estimation better, based on your experience and ability on spending on your tasks. If you finish all the tasks very earlier than expected estimation time, or over-commit your promise, are considered bad/failed sprint. Improve it on next sprint.