You are all set with you team on the Daily Scrum Stand Up. Your Sprint Planning and Sprint Retrospectives are flying smoothly. You got your Backlog grooming down to a T.
Yet with all the things going so smoothly your Project Owner is still uneasy on the project's end date. Sprints every 2 or 3 weeks does not make them easy on when will the project be finished.
I’ll show you an example if you are using JIRA you can utilize Epic Burndown Report and provide an easy of mind on the end date to your Project Owner.
Scrum Master might provide Epic Burndown report As Is to the project owner. However, this will not provide a possible end date which will further make the Project Owner uneasy.
Epic Burndown report provides all the Sprints that have been completed, the number of Story points committed by the team and completed during a particular Sprint, as well as Incomplete Stories and their associated Story points.
Below is a sample Epic Burndown report.
All you have to do is export all the Completed Sprits Stories as Tasks, with the Sprint start and end dates. Since you already have number of Stories that your team can produce during a Sprint. And, you have your Incomplete Stories priorities in the Backlog. Break down all Incomplete Stories into the 2 or 3 week future Sprints increments.
Now you have completion date to show to the Project Owner of when the project will be finished.
So use you Agile and presentation skills and remember to make your Project Owner feel at ease. Saving Changes...
But using them to figure out an estimate of when you will be done starts with a consistent iteration length. Then figure out the average they can complete per iteration. Compile the estimated total effort, divide by the average effort done per iteration and you have the number of iterations needed. If you have a project level burndown chart, you already have the estimated total effort.
If you need to know in the beginning when you will be done, you can do that too.... the same way you estimate how a standard project will be completed - manager ordered "Need by this date"
Don't bother making the product owner feel at ease. It's more fun to make them uncomfortable. Use the word "Should" a lot and "I Think" when at the end of every answer to their question. Saving Changes...
If you are using JIRA, I'd suggest using the Version report unless a release is defined as only covering a single Epic.
Of course, this does require that all relevant work items for the release are associated with that Version and that the majority (90+%) of them have been recently sized so that the forecasting of the cone of uncertainty is somewhat reliable.