Ability for TFS sprint capacity and days off for a project to be inherited by teams
This suggestion is migrated to Developer Community. Please use below link to view the current status.
For businesses where a single scrum team works on multiple projects/products per sprint, sprint planning is painful in TFS 2015.
One approach is to have a single TFS project and teams representing each product. This simplifies backlog management. However, capacity planning is still time consuming.
I would recommend capacity planning for a team has a checkbox to "Inherit capacity and days off from parent project". This would allows only having to set capacity and days off at the TFS project level without having to duplicate it at the sub-team level.
Currently TFS is not designed for single scrum teams with multiple products in a sprint, and this would go some way to make TFS more usable for small businesses.
I would much rather copy capacity from the previous sprint; copying from your project-level would be fine for days off, but I don't see how it's helpful for capacity.
@Agile Software Development You can't say it's always inefficient to split a team or individual across multiple products, if the products are not big enough to occupy all of that resource's time. Wouldn't it be much more wasteful and inefficient if they spent their extra time twiddling their thumbs instead of working?
I don't understand why you'd want to inherit the capacity; are you saying they spend exactly the same amount of time on each product?
Heath Upton commented
I created this idea in 2015 and recently upgraded our on-premise TFS to 2018.1. I thought it was time to review the idea and reply to some negative comments.
I'm amazed to find that even with TFS 2018.1 there has been no improvement that I can find to capacity planning or to improve support for small agile teams. Whilst I admire TFS, Microsoft are ignoring SME's like us, who have a single team that have to work on multiple projects during a sprint. Yes, even a single small agile team can use SCRUM.
Whether we have a separate TFS project for each product or have a single TFS project with multiple teams (products), management of the backlogs and resource capacity is extremely painful.
Hope more smaller agile teams feeling the pain with vote for this for starters.
Joshua Omundson commented
I don't think the OP is ignorant of the Scrum Framework. I know at my job, we have a lot of little unrelated apps that don't always require updates, so they are all grouped under one team. And sometimes, two or three of the apps have requested updates.
In this case, it makes sense to have a team split among multiple apps (otherwise we would have teams committed to one app sitting around doing nothing). TFS does need to be flexible enough to support this.
Agile Software Development commented
The OP and many comments highlight the ignorance throughout the industry as to the Scrum framework: https://scrumguides.org/scrum-guide.html
It's 2017 and many continue to work under well-known misunderstandings. Splitting a team or even a single person across multiple projects or products is wastefully inefficient.
Unless you are using TFS/VSTS for highly predictable manufacturing work, (if so why are you using this product?), such hours-based planning is ridiculous. The continuing dysfunction is evident in the comments.
Martin Underwood commented
I agree with Raju, this is the biggest gap in TFS. Not even looking at it from a Project Management aspect but from a development manager. One person (resource) has a limited amount of hours they can work each day, why in the world TFS allows you to allocate a person unlimited number of hours per day seems like a bug to me. It doesn't matter what projects/sprints they are working on, the restriction is common sense in my opinion.
Shalem Raju commented
In VSTS, How to constraint/restrict a team member's working capacity in case working in multiple projects.
Assume a team member A works with multiple projects/applications(P1,P2,P3). While doing Capacity planning, i'm able to allocate him with 8hrs per day in each project(P1,P2,P3). Is there any availability to freeze/constraint a team member's capacity to 8hrs in all projects combined(capacity should be restricted to 8hrs in combined). This would be of great help.
Don VanVooren commented
This would provide great visibility to our Management team as they would have access to team projects at a higher level
David Bottiau commented
Another possible solution would be to create a project/product sprint around a team sprint. I mean, The "My team" group has a collection of sprints and each sprint can be linked to the projects/products the group intend to work on.
Would like to track planned capacity / sprint to actual. Planned includes allocation for scheduled absences, but if someone calls in sick, there is no way to capture that as an unplanned impact to capacity.
Maybe keep it on the project itself, since availability can be different to multiple projects. Adding it to your user profile would make that harder to manage.
Would like to be able to add a comment as well so others can see why someone is not available. For example, on holiday or doing some other project elsewere.
Kevin Auch commented
We often work with part-time, and it will be great to be able to choose fix day of presence by week.
Would be awesome :)
Okko Oulasvirta commented
Add global capacity planning functionality for multiple teams and projects so that people in resource planning may use vsts as resource planning tool
What I would like to see:
- Enter working days/days off once for all employees and have each project look in that global calendar so I don't need to enter it for each project
- Instead of capacity per day, allow me to enter a capacity per day of the week
It would be great if this functionality would allow easier capacity integration with MS project. Currently I need to update peoples availability in TFS and MS project, based upon an excel calendar being completed by the team. If we could have a one-stop-shop, allowing all team members to update this, it would give me at least one hour per sprint less waste :-)
Barry Postma commented
Agree with @Fokko and @Harald-René.
Would like to add that apart from people working on specific days during different weeks (even inter-sprint) people working only for 4 hours on one day would be nice to register in the sprint.
In an SMB like ours scrumming developers are usually also assigned to other - non TFS - tasks for 2-4 hours a day. The current way of calculating hours backwards over the available days without specifying leave is too laborious.
James Hanley commented
To me, this seems like an integration point to Exchange or PeopleSoft or whatever system used for tracking office hours, vacation, or PTO - not a core function of TFS and not a a redundant feature to the above systems that then needs to be either synchronized or updated in multiple locations by the end user.
I'd like to be able to put a comment next to days off - people always seems to forget if is it because of vacation, holidays, other work, etc.