Considering 100% capacity for each team member will lead to overtime and Stress in the team environment. So, it is never recommended.

Before the sprint starts, in the sprint planning meeting Scrum Master can prepare one excel SHEET containing a column of the name of each team member, any vacations planned, % contribution for the project.

Consider a 2 weeks Sprint, 10 days and 5 people on board, the table may look like this:

Going beyond 0.8 can be risky and can derail teams too.

In this sprint, the total available working hours for the team is 190 hours. The reason for asking the productivity for the sprint is that out of 8 hours per day we NEED to spend on meetings, some presentations, interviews, and Mails etc. Generally, we consider 6 hours a day of each team in which they work to their full capacity. The why 50% or 60%? The reason could be 

1. A team member might have to work on 2 projects. (Sometimes other team needs the help of this person)
2. A team member has to spend time on technical debt for some other project also.
3. A team member is in training for a few days.
4. A team member is allocated to support maintenance activities also.
5. Ceremonies
6. Unplanned work

After arriving the figure called 190 hours the same can be filled into the Project Management tool.

But the question may arise why hours??? Here we are calculating tasks details which are done in a number of hours. i.e. BREAKING the user story into tasks.

To the question about team member working on multiple projects. Ideally “Not recommended”. But It depends upon the situation. When doing heavy development, it is better to have a single product. If doing lighter enhancements, multiple products can be supported.

The "rule of thumb" to address that is to work on one product until you have SOMETHING to deliver, and only at *that* point chooses whether the next deliverable thing will be from this product or the other. Working on 2 different features at the same time delays the delivery of both - even when for the same product. If you already know you WANT them both finished before you deliver, then working in parallel is not too much of a problem; other factors than early ROI and early feedback from having delivered, take precedence. But this rarely applies when working on 2 different products that are very likely to have independent delivery cycles.

Keywords