Estimating with story points in a non cross-functional team

We have to report to the management: how much time the team spent with developing a product (in hours).

Why? Before we even consider improving an estimation method, how is work for each product being planned into a Sprint and product value accounted for? How is Product Ownership being represented in the team?

Fifteen products is a lot for one team to work on, while maintaining commitment and focus to a clear Sprint Goal.

All products have the same Product Owner, so PO is prioritize and the team have only one backlog from all products. 

Dorina, before addressing your estimation concerns, I would appreciate a little more clarity around your situation:

• How many items does your backlog of 15 products contain?
• Typically, how many different products are part of the Product Owner's "offer" to the team each sprint?
• What has your experience been working with the PO and the Development Team in identifying Sprint Goals?

Around 3-4 products are part of the Product Owner's "offer" to the team each sprint

We do not use sprint goal, because of this situation. 

I am in a similar situation right now.  We have 5 scrum masters, 6 POs and 11 teams. We do not have what I would call Product Backlogs. I call them Team Backlogs because there are multiple "products" represented in the backlog.  We also have 1 PO for of the products in a single Team Backlog. Our POs are good about ordering the items in the backlog so that we can focus on 1 product at a time per sprint.  We create sprint goals towards the "focus product" and pull enough of those stories into our sprints to provide adequate value (per our POs) on those products.  Any additional bandwidth (per the Development Team) is filled with various stories from the backlog but may not be associated to our focus product (i.e. technical debt, production defects, etc). 

This is a very simplified view of how we deal with the accounting part.

We do story point estimation but we do ours more towards effort and not hours.  Our product and engineering management has accepted that hours worked on a product is not the proper measure.  They measure based on the value to the end user that we are delivering.  For accounting purposes we use a fixed number of hours per person per sprint based on the number of Development Team members.  Those numbers are applied across the products based on the goal of the sprints.  At the end of our quarter a determination of the number of sprints per "focus product" is derived.  The accountants then do their magic.

We started to estimate in story point without taking care of this problem. It works quite well, but the team is not enough happy, they would like to know how many tasks could be put in the sprint from 1-1 product. 

I am not quite sure what the scrum says in this situation. I feel that there is no really cross functional team in the real word. 

I have 3 different team, which are not cross-funtional. They are said because they feel that the sprint can be unsuccesful even though they have no more work in the actual sprint. 

they would like to know how many tasks could be put in the sprint 

This is the first problem I see.  You put Product Backlog Items (PBIs) into a sprint, then add tasks to support work needed to satisfy the PBI. A PBI is typically a description of a feature you want to build or a problem you are trying to solve.  If a PBI is too large to be completed in a single sprint it is an Epic.  Epics are broken into smaller PBIs that can be completed in a single sprint. However instead of splitting the Epic horizontally (i.e. build the backend, build the middle tier, build the presentation layer in 3 sprints) you would split them vertically (i.e. build a system that will display data from the DB, add the capability of modifying the data in the DB, add the capability to create reports of the data being modified in 3 sprints).

By splitting vertically, all of the skills in a cross-functional team will be utilized each sprint and you will incrementally deliver value that can be shown to a stakeholder. 

Remember that a cross-functional team does not mean that everyone on the team can do all of the work. It means the team has people on the team that is capable of doing all the work.  If the team chooses to self-organize into specialist, they can still be cross-functional.  However there are risks associated to that plan. The has to understand and accept the risks. The organization has to let the team make the decision, honor it and hold them accountable for the risks that they have taken. 

All of the teams at my current company are cross-functional and successful.  It does happen.