I am working with TFS and I set the story points for all the user stories using the Fibonacci series and set the velocity of the team. TFS has a field called ´Remaining work´ for the sub-task, it is a value in hours. Is recommended working with this field or how can I use it because the philosophy of Scrum is not working with exactly hours, or am I wrong?
Some teams, especially those that are new to Scrum, use a combination of story points and task hours.
The story points set the capacity of the sprint, but the task hours allow the team to do several things:
- Ensures no individual in the team is overloaded in the coming sprint
- Ensures that no task is to big (e.g. some teams set a maximum limit of 1 day for tasks)
- Gives a forum for the team to discuss each task in detail
- Gives a sanity check on the story point capacity (e.g. once the task estimates are done, does the story points allocated to the sprint still make sense?)
Not all teams will find task hours useful. A lot depends on the circumstances of your organisation and how much experience with Scrum the team has. Estimating in both story points and task hours represents waste and the only reason the team should do it is if they get some obvious value from this approach.
Using the "remaining work" field is not a problem as long as you don't mix it with story points. IMO, both are not compatible to one another. Nevertheless, there's still a possibility of using both at the same time for different purposes, e.g. the story points for velocity and the "remaining work" for reporting. Just remember that you might be adding a bit of complexity (and perhaps, confusion) to the team when you're using both measurements.
PS: I personally will stick to story points when I'm not required to do time tracking.
Is a good practice to set the remaining work of a Sub-task?
A good practice is something beneficial for you / your team. Most of the answers here will be focused on personal experiences rather than a canonical answer.
Having that said, is important to remember one of the Principles behind the Agile Manifesto:
Simplicity--the art of maximizing the amount of work not done--is essential.
So, if your team needs and will benefit on tracking hours and have remainings at subtask level, then go for it. But avoid doing anything with your team because it works for another team.
It is often a good idea to use hours on tasks to track Remaining Work and plot that on a burndown.
The Scrum Guide
The Scrum Guide only requires that a team have a plan to complete the selected backlog items and be able to easily understand the remaining work.
TFS/VSTS & Scrum
Hours on Tasks - This is the most common way to figure out your remaining work. It is simple, quick, and has very little waste. Simply updating the field of the task in TFS is very minimal at the end of each work session. The benefit you get in TFS/VSTS is to get a burndown in the web access or reporting services.
Number of Tasks - even easier, but requires more discipline in the team in creating discreet tasks that are more normalised in size. In TFS/VSTS you will not get a burndown for this (unless you have a rule to always put a 1 in each task). You can get this report in TFS with reporting services, but not in VSTS without from code.
Acceptance Tests - it can be very effective to monitor remaining work in the number of acceptance tests that have not yet passed. You can create a dashboard burndown with a query on the year plan for the Sprint and pin it to your home page.
The Remaining Work field in TFS/VSTS does not require hours, that is simply the convention. You can use any numerical value you like. Hours, days, nebulous units, whatever...s long as it has a value you get the features.
I have some customers that use TFS that set a default value in the process template for the task work item type definition that makes this easier. This is not currently available in VSTS.