How to accurately measure estimate without design as a Front End developer in agile?

Question

I am a front end developer with 2 years experience, I am new to agile and I am having difficulty doing estimates to for user stories since I don't have any design for it? I am not sure how can I give estimate without even seeing a wire-frame and just by user story definition? We are following scrum as I have been told. I even asked my lead that how much does estimates depend on the design and both web and mobile gave me the answer 95%. But our manager said it can be done, so is there a way to give estimation without design?

Is it allowed to be revisited at a later time? What happens when I realize that the particular user story UI has a lot of animation and flashy stuff that throws out my estimation, is it recommended that I change my estimation on user story or to better phrase the question as a developer, how can I better inform team that my estimation of the complexity of the work changed in light of new info and it will affect the sprint?

I realize that creating UI first then building API and Front-End is not how agile works so I am assuming front-end does need to estimate before any design

question related to explanation of why it is bad to make design first

Answer 1

If you are following Scrum, the team should be carrying out backlog refinement activities. During refinement, the team will decompose the work into smaller slices, add new details and descriptions of the work to be done, reorder the work, and size or estimate the work. The team may add or remove other attributes based on what they feel is important. Even if you aren't using Scrum, there's probably similar activities to make sure that the team fully understands the work.

Design, at the appropriate level of abstraction, is usually part of refinement activities. This design could include both user interface design as well as software architecture and design. The depth and detail in the design should be sufficient to make sure that the team has reduced risked to an appropriate level and can give confidence that the work is well-understood and achievable, especially within the timeframe of an iteration or Sprint.

During refinement and design, the team should be figuring out what the minimum required work to add value. If that means that the UI needs to have a lot of "animation and flashy stuff", that should come out and the team should be able to account for it in the estimates. However, if it's not necessary, a more minimal UI could be designed and additional changes can be put on the backlog for later design and implementation.

If development work happens and changes your understanding of work yet to be started, the team should revisit that work with this new understanding. This may change the designs and estimates, as well as the planning of the work.

Answer 2

I am not sure how can I give estimate without even seeing a wire-frame and just by user story definition

The user story should tell you enough to know what elements you are going to need to put on the page. Estimate how long it would take you to do that for a "basic" design and include that caveat in your estimate.

and is it allowed to be revisited at a later time?

There is no "Global Agile Police Force" that will come and arrest you if you think your estimate needs revision in light of new information you have received. What your company might do with that revised estimate is entirely a question for them, nobody here can tell you that.

I realize that creating UI first then building API and Front-End is not how agile works

"Agile" does not specify this one way or the other. It many cases it seems like a very good way to work because users are probably going to give more effective feedback on a UI mockup than they are on an API definition.