Backlog in Scrum

It is a new project, so we are basically learning/discovering things as we go along, so 3 months seems a long period considering the uncertainity and lack of clarity.

Did you delivered any increment yet ? 

What would be the probability that the items defined 3 months up front will actually have the same value, size, estimation and details when the three months have passed?

Regarding the Scrum Values, (dis)respect pops to mind when you would be doing double work consistantly re-estimating these user stories and thus spending more of the customer's money.

Besides that, the Scrum Team does not get instructed to do anything with the backlog. The Product Backlog is owned by the Product Owner and the Sprint Backlog by the Development Team. Inherently these roles are the sole ones deciding on what and how to deal with it. It is the Scrum Master's job to make sure transparency is sufficient, but they way you are describing the situation is counter productive.

How do you guys handle the backlog in your teams and how far ahead do you refine the stories? 

Let's put that aside for the moment, because what other teams do may not be appropriate for yours. Much depends on balancing just-in-time efficiency with the management of risk, for example, which can vary greatly by product.

In our company, POs and Scrum master have been instructed to ensure that we have a visibility up to 3 months in backlog.

In my opinion, it is a bit exaggerated.

The Scrum Guide says:

The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.

and

The Product Owner is the sole person responsible for managing the Product Backlog

Your SM and PM were apparently "instructed" to ensure visibility of up to 3 months in the backlog. Does your Scrum Master consider this interaction to be helpful?

Since visibility and transparency are not the same thing, you might want to ask some tough questions to your instructors. because at first glance, it seems PREDICTABILITY seems to be the argument here, not transparency.

On a high level, like a roadmap, it can be helpful to indicate themes for the next months to come, but you should be wary for creating all forms of waste asscociated with going to far into the future.

Try to balance transparancy, predictability, waste, value, just in time delivery etc into one. Ask yourself the question: should we trade "transparency" for waste?

Well, to make it clear; I'm the Scrum Master and I have been told to push the Product owner to get more refined backlog.

But i don't think that it is a great idea.

But the counter argument from management is that goal of this exercise is to help the development by providing the following:

• More visibility/high level overview of what is coming next?
• It helps them understand the bigger picture?

But does it mean that we need refined backlog? I don't think so?

What other alternatives could we use to help the Scrum team if they are missing the high level picture?

Am I missing the point?

How quickly does your market or business change? 3 months of refined backlog items could turn out to be a wasted effort if you need to change direction based on new learning. 

A goal oriented product roadmap can illustrate where the Product Owner intends on taking the product over the next 3,6,12 month horizon without getting into the details. Typically the farther down you look in the Product Backlog the less granular it is. 

Starting with a couple of quotes from the Scrum Guide section on the Product Backlog and as usual I added some emphasis.

The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases.

Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process in which the Product Owner and the Development Team collaborate on the details of Product Backlog items. During Product Backlog refinement, items are reviewed and revised.

Higher ordered Product Backlog items are usually clearer and more detailed than lower ordered ones. More precise estimates are made based on the greater clarity and increased detail; the lower the order, the less detail. 

Now, here is how I coach the Product Backlogs are usually handled on teams with which I am involved.

Top of the Product Backlog has the most refined, best understood items.  Bottom of the backlog has any idea that has crossed the Product Owner's mind and no one other than that individual really has any understanding of what it means.  As items leave the top of the Product Backlog, for what ever reason, something a little lower in the backlog starts to become more clear. This provides transparency into what the Product Owner feels needs to be done to the product and also helps others know what is most likely to be worked on in the near future.

For you, all of those Epics that you don't feel are ready to be refined would be at the bottom of the backlog.  Anything you have ready to be worked on for the next sprint or two will be at the top of the backlog.  In between those, could be any number of items in various stage of refinement.  Would you have 3 months visibility of items?  Not entirely sure but you would have visibility into varying degrees of known items that are thought to be needed for the products continued viability. 

Refinement does not have to mean complete and full understanding.  Refinement is based on the acts of discussion, discovery and capturing of new information.  Since conditions change constantly it really doesn't do much good to have more than 1-2 sprints worth of items fully ready to be pulled into a sprint. But that doesn't mean that you should not have any ideas of future work that is thought to be needed, even at a very high level of understanding.  That type of information could help the Development Team predict when some item of technical debt will have to be addressed in order to continue to provide further work.  Or it could influence a decision on a technical implementation knowing that at some point in the not too distant future there is a high chance that something new will be needed. 

Thank you @Daniel, your answer makes lot of sense in my case.

We do have enough refined stories to fill about 2 sprints, which seems enough to me.

For the work beyond 2 sprints, in my case, we just have "epics" with high level estimates, but these epics don't appear in the backlog in JIRA as there are no stories refined for those epics?

So, shall I just create a placeholder story in these epics and put rough estimates, so that it appears in the backlog?

If there is a better alternative to represent this information, please let me know, it will be really helpful to have this information, before I can challenge my manager that it is useless to refine stories for 3 months in advance.

For the work beyond 2 sprints, in my case, we just have "epics" with high level estimates, but these epics don't appear in the backlog in JIRA as there are no stories refined for those epics?

So, shall I just create a placeholder story in these epics and put rough estimates, so that it appears in the backlog?

The Product Backlog should capture how much work is thought to remain, irrespective of its granularity. You'll therefore need some way of accounting for it.