A lot can impact your velocity number. The kinds of tickets you have been taking, your mood, how you approach your work, etc. etc. This article is about what I do to consistently deliver a high number of points.
Establish why this ticket was prioritized. What do we hope to accomplish? Often the why is lost in a sea of technical requirements, product asks and commentary with stakeholders. To find the true why it may require you to follow a technique called Abstract Laddering.
This is a thought process that helps you move from concrete requirements to abstract asks and back down. To identify the why. Given a position on the ladder ask why to move up a level and how to move down a level.
Lets say you are assigned a ticket that has the title "Make the can opener more appealing". You could start doing research on what makes can openers appealing and prototyping options. OR you could ask why. Why do I have this ticket? If its not defined in the ticket why, ask your tech lead or product manager Why?
You might get an answer "We want to design a better can opener". Great! Now you have options. Appealing is just one way to improve the can opener. Some of these options may even cost less points to deliver to production.
Perhaps you didn't get to any good options when you learned your company really wants to "design a better can opener". Sometimes to find the easy way to deliver the ticket you have to go deeper.
Push past the initial answer and continue to ask questions until you can move up a level of abstraction. Why does your company care about designing a better can opener? This can lead to new options to deliver.
Assume you found out that your company only cares about can openers because "they want to help people get soup out of their cans". Whole new options open up for delivering your ticket! You could even add a pull tab to the top of cans!
The point of all this is to identify an implementation that gets your company what its looking for but costs significantly less than the original estimate.
Keep in mind this is a negotiation process with your peers. If at the end of the sprint your tickets are done but no one is happy then you have lost. Make sure you really are building the right thing but do not feel constrained by the tickets you are given.
In the middle phase of a long project I often find myself lost. Unclear what is left and how much longer its going to take to get there. A useful mantra to adopt to find your way out is to ask yourself "Could I ship this feature today? If not why?".
Work through the set of changes in your mind that are preventing you from completing this project. Focus your energy on the work that is truly "blocking" from complete. Regularly ask yourself this question.
Tickets are never the exact minimum viable product change needed to accomplish a goal. There are often miscellaneous changes tacked on. Sometimes those extra changes drastically increase the cost of the ticket.
Product managers are often willing to negotiate with engineers. Often through conversations and a keen eye you can split large tickets apart and put the lower priority work back into the backlog.
The number of points you complete in a sprint mostly doesn't matter. Your primary purpose as an engineer is to deliver value to your organization. The value you bring is though building or changing software. Focusing on these techniques can help you avoid getting bogged down building low value changes over extended periods of time.