Let me give you a bit of advice, whether you are in a product position, a developer or business analyst never give the business an estimation for the delivery of a thing based on time. Don’t even mention days/weeks/months or even years! Get the message?!
Instead, use (or invent) a measure of time that you can apply meaning to, give it a name and use it consistently across your projects. For example, we’ll use jelly beans and we’ll call the units “JB’s”:
We aren’t going to tell the rest of the organisation what each jellybean amounts to (a developer minute, hour, day etc). But we will let the business know that they have X amount of JB’s to spend on a given project, and we’ll keep some spares for tech debt, maintenance work and a little bit of leeway just in case something was missing from the original brief.
This can be a hard concept for a company to grasp especially if you are adopting agile for the first time but it pays off in the long run. The number of JB’s you originally assign to a project at first might be way off, but over time you’ll get better at assigning the correct amount, and this is a great way to detach the concept of delivery measured in effort rather than time.
Story Points
Story points are a unit of measurement that are assigned to a user story to represent the level of effort required. You define story points by breaking down the user stories into relative units of size, but relative to what?
Choose something that most or all developers have done, this could be any development task that doesn’t only take a minute such as applying validation to an email field. Then use this common task as a baseline when assigning points to other user stories, decide how much more or less complex a given story is when compared to the baseline task, this should provide harmony amongst the development team when sizing work.