Using story points at sub-tasks level to identify the team sprint velocity

We have 3 weeks sprint cycle.

From what you say, you have no Sprints at all. The whole point of a Sprint is to meet a Sprint Goal by producing at least one Done increment of immediately usable work.

That doesn't sound like it's happening, and the empiricism you'd expect from the Scrum framework is not therefore being established. I'd suggest that, rather than trying to resolve the symptoms you describe, it might be better to focus on that more fundamental issue.

Thanks, Ian Mitchell.

I understand. Actually, there will be at least one done increment in each sprint cycle as some of the stories will come to end in each sprint cycle. however, it will be like we planned for 10 stories but we only completed 2 in the sprint cycle. 

These 2 stories might have taken 3 sprints to complete.

I agree with @Ian.  You are trying to fix the wrong problem.  Your difficulty is that you are not breaking items down into something that can be done in a single Sprint.  This comes from the Sprint Guide section that describes the Product Backlog. 

Product Backlog items that can be Done by the Scrum Team within one Sprint are deemed ready for selection in a Sprint Planning event. They usually acquire this degree of transparency after refining activities. Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

You state 

• The story represents a request for a single training course that can be broken into lessons or learning objectives but it doesn't make sense to create a story for each lesson/learning objective. Also, the course request can be broken into lessons post-planning phase only and that is the part of the development phase.

Why doesn't it make sense to create a story for each lesson/learning objective if it will allow you to complete a body of work in each Sprint? The intent of a Sprint is to provide a valuable increment of work.  In software development it is quite common for teams to deliver portions of working code that will be built upon to create a feature. For example, we may deliver a set of code that interacts with a set database tables and displays part of the information the user needs in the first Sprint. The next Sprint does the same with a second set of tables.  It may take us 4 Sprints to completely present all of the data that the user wants but we are able to give them pieces of information every Sprint. 

In your case, the training course may not be able to delivered until all of the parts are ready but you can still create complete work each Sprint.

@Ian mentioned that you are missing out on the empiricism that is so valuable.  If you aren't familiar with empiricism, it is the belief that all knowledge is gained through experience.  In Scrum, and many other agile iterative practices, a big benefit is being able to get user feedback quickly and then adapting to that feedback as you go.  That is the main purpose of the Sprint Review. It is a time that you can share your incremental progress with your stakeholders and gain feedback, which is then incorporated into your Product Backlog. 

Now, let me give you this caveat.  Both @Ian and my responses are based upon the Scrum framework.  I raise that point because your description of what you are doing does not sound like you are using the Scrum framework.  Using terms like Sprint does not mean you are using the Scrum framework.  Also since you never mentioned a Sprint Goal, or any of the other artifacts/events in Scrum it isn't clear that you are fully using the Scrum framework.  User Stories are not mentioned anywhere in the Scrum Guide and your entire question is focused on them. There is nothing wrong with using some of the terms or practices of Scrum in combination with other methods, procedures, and practices.  But as the Scrum Guide says in the End Note

While implementing only parts of Scrum is possible, the result is not Scrum.

These 2 stories might have taken 3 sprints to complete.

If that's the case, then your velocity can be stated as being 2 stories per 3 Sprints. Velocity is the rate at which work is Done.

For planning purposes your velocity of stories per Sprint is zero, in so far as within any one Sprint, you cannot expect that any one story will be started and brought to completion.

From what you say, you could arguably plan to retire technical debt at a rate of 2 undone stories per Sprint. The problem is you will continue to accrue technical debt at the same rate, a situation which has evidently become normalized. That's the core issue you need to resolve because it's hobbling empiricism and causing the feedback you'd expect from Scrum to become attenuated.

Thanks, @Daniel Wilhite and @Ian Mitchell for your responses. These are really helpful.

I will work on your recommendations.

Thanks

Sharad Singh