20 points work... could be 2 design, 2 IOS, 2 Android and 14 backend points.

There are three ways to resolve this issue.

Option one: Allow more "user" types A user doesn't need to always be a human end-user. Not all features are exposed to the human end-user. So the client and the server can be actors in user stories. A peripheral, like a stylus, headset, or robot that interacts with your app might also be a user. The client developer (iOS or Android) may be treated as a user in a user story such as, "As a client developer, I need an API for data storage so that I can add user data to the database".

Option two: cross training Scrum encourages team members to self-assign tasks that they aren't the best at, but that they have capacity to help with (see: T-Shaped People). It is better for the UX designer to make slow progress on an update to the client UI code (or to do some quality assurance work or write some product documentation) on a user story that has already been started by the team than it is for the UX designer to begin designing a new UX spec for a new user story that is lower priority and hasn't been started.

Option three: try Kanban Maybe, for your team, a Kanban approach is a better fit than Scrum. Kanban progresses user stories through a workflow, chosen by your team to fit your organization. Perhaps in your organization you'd want five workflow states: (1) To do, (2) UX design, (3) Client, (4) Backend, (5) Done. If you pick this approach, consider what states a user story should move through and what sequence handoffs of primary responsibility should occur in.

Note: the objective of either Scrum or Kanban is increasing the team's ability to make reliable customer delivery commitments and responsiveness to changing customer needs or feedback. The objective is not to keep all team members 100% busy 100% of the time. So if your UX and client people are only busy two days a week and backend person is working seven days a week, then you don't need to change your estimating you need to hire (or cross train) another backend developer. Or you may need to choose an alternative technical approach, like moving to a PaaS or making better use of an open source library, or eliminating a feature that users really don't use.

20 points work... could be 2 design, 2 IOS, 2 Android and 14 backend points.

There are three ways to resolve this issue.

Option one: Allow more "user" types. Different types of users have different needs (see As a, I need, So that). A user doesn't need to always be a human end-user. Not all features are exposed to the human end-user. So the client and the server can be actors in user stories. A peripheral, like a stylus, headset, or robot that interacts with your app might also be a user. The client developer (iOS or Android) may be treated as a user in a user story such as, "As a client developer, I need an API for data storage so that I can add user data to the database".

Option two: cross training. Scrum encourages team members to self-assign tasks that they aren't the best at, but that they have capacity to help with (see: T-Shaped People). It is better for the UX designer to make slow progress on an update to the client UI code (or to do some quality assurance work or write some product documentation) on a user story that has already been started by the team than it is for the UX designer to begin designing a new UX spec for a new user story that is lower priority and hasn't been started.

Option three: try Kanban. Maybe, for your team, a Kanban approach is a better fit than Scrum. Kanban progresses user stories through a workflow, chosen by your team to fit your organization. Perhaps in your organization you'd want five workflow states: (1) To do, (2) UX design, (3) Client, (4) Backend, (5) Done. If you pick this approach, consider what states a user story should move through and what sequence handoffs of primary responsibility should occur in.

Note: the objective of either Scrum or Kanban is increasing the team's ability to make reliable customer delivery commitments and responsiveness to changing customer needs or feedback. The objective is not to keep all team members 100% busy 100% of the time. So if your UX and client people are only busy two days a week and backend person is working seven days a week, then you don't need to change your estimating you need to hire (or cross train) another backend developer. Or you may need to choose an alternative technical approach, like moving to a PaaS or making better use of an open source library, or eliminating a feature that users really don't use.

20 points work... could be 2 design, 2 IOS, 2 Android and 14 backend points.

There are three ways to resolve this issue.

Option one: Allow more "user" types A user doesn't need to always be a human end-user. Not all features are exposed to the human end-user. So the client and the server can be actors in user stories. A peripheral, like a stylus, headset, or robot that interacts with your app might also be a user. The client developer (iOS or Android) may be treated as a user in a user story such as, "As a client developer, I need an API for data storage so that I can add user data to the database".

Option two: cross training Scrum encourages team members to self-assign tasks that they aren't the best at, but that they have capacity to help with. It is better for the UX designer to make slow progress on an update to the client UI code (or to do some quality assurance work or write some product documentation) on a user story that has already been started by the team than it is for the UX designer to begin designing a new UX spec for a new user story that is lower priority and hasn't been started.

Option three: try Kanban Maybe, for your team, a Kanban approach is a better fit than Scrum. Kanban progresses user stories through a workflow, chosen by your team to fit your organization. Perhaps in your organization you'd want five workflow states: (1) To do, (2) UX design, (3) Client, (4) Backend, (5) Done. If you pick this approach, consider what states a user story should move through and what sequence handoffs of primary responsibility should occur in.

Note: the objective of either Scrum or Kanban is increasing the team's ability to make reliable customer delivery commitments and responsiveness to changing customer needs or feedback. The objective is not to keep all team members 100% busy 100% of the time. So if your UX and client people are only busy two days a week and backend person is working seven days a week, then you don't need to change your estimating you need to hire (or cross train) another backend developer. Or you may need to choose an alternative technical approach, like moving to a PaaS or making better use of an open source library, or eliminating a feature that users really don't use.

20 points work... could be 2 design, 2 IOS, 2 Android and 14 backend points.

There are three ways to resolve this issue.

Option one: Allow more "user" types A user doesn't need to always be a human end-user. Not all features are exposed to the human end-user. So the client and the server can be actors in user stories. A peripheral, like a stylus, headset, or robot that interacts with your app might also be a user. The client developer (iOS or Android) may be treated as a user in a user story such as, "As a client developer, I need an API for data storage so that I can add user data to the database".

Option two: cross training Scrum encourages team members to self-assign tasks that they aren't the best at, but that they have capacity to help with (see: T-Shaped People). It is better for the UX designer to make slow progress on an update to the client UI code (or to do some quality assurance work or write some product documentation) on a user story that has already been started by the team than it is for the UX designer to begin designing a new UX spec for a new user story that is lower priority and hasn't been started.

Option three: try Kanban Maybe, for your team, a Kanban approach is a better fit than Scrum. Kanban progresses user stories through a workflow, chosen by your team to fit your organization. Perhaps in your organization you'd want five workflow states: (1) To do, (2) UX design, (3) Client, (4) Backend, (5) Done. If you pick this approach, consider what states a user story should move through and what sequence handoffs of primary responsibility should occur in.

Note: the objective of either Scrum or Kanban is increasing the team's ability to make reliable customer delivery commitments and responsiveness to changing customer needs or feedback. The objective is not to keep all team members 100% busy 100% of the time. So if your UX and client people are only busy two days a week and backend person is working seven days a week, then you don't need to change your estimating you need to hire (or cross train) another backend developer. Or you may need to choose an alternative technical approach, like moving to a PaaS or making better use of an open source library, or eliminating a feature that users really don't use.