2

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?

4

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.

  • How do you do with your team? – Sebastián A Jun 14 '16 at 14:28
  • I'm a contractor so I have had many teams over the years. I have found estimating in hours on tasks is useful if the team has a lot of specialists. For example: a tester, a front-end developer, a back-end developer, etc. By estimating in hours you can check that nobody is overloaded (it is usually the tester that gets overloaded!). If the team is made up of non-specialists then we don't usually bother and just concentrate on story points. – Barnaby Golden Jun 14 '16 at 16:36
  • When you work with specialist, do you also work with story point or only whit hours? If yes, how do you combine the story point and the hours? – Sebastián A Jun 14 '16 at 19:51
  • 1
    Both story points and hours. First you estimate in story points. Then you assign stories to the sprint based on your velocity. Once this is done, the team then starts to break stories down into tasks. For each task they estimate in hours and work out who is likely to do the work. When all the stories are broken down in to tasks and all the estimates done you then check to make sure no individual is overloaded. e.g. 2 week sprint might mean 60 hours available per person. If your tester has 80 hours work in the sprint then it is too much and something should be taken out. – Barnaby Golden Jun 14 '16 at 22:00
  • 1
    I recommend the book "Agile Estimating and Planning" by Mike Cohn. It covers this in great detail. – Barnaby Golden Jun 14 '16 at 22:02
2

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.

  • when you use hours instead of points of history, philosophy scrum focused on a reliable velocity rather than a estimation accuracy is lost, no?. I read this article. blogs.atlassian.com/2012/09/… – Sebastián A Jun 14 '16 at 14:39
  • 1
    Yupe. That's the idea. However, if you really need to track the time, then you can use both. It really depends on your situation and needs. – Amir Syafrudin Jun 15 '16 at 1:05
  • The customer wants: that the scope is 6 months the price of all the project to approve it So I need to set the team members to say the customer how much it cost. The question is: How I cost that project? Based on story points? Based on task hours? In TFS there is the forecast option that based on my velocity it split the user stories into the sprints, so, That is the option that I need? If there is differents roles (front end, back end, etc) how can I set the velocity? This team members are new in the company so we not have experience as a team. – Sebastián A Jun 15 '16 at 13:50
  • So it's really about cost estimation? Well, there are definitely more than one way to estimate cost, but I've never really used story points for that. The most straight forward way to do it is simply estimate how many person you're employing x how much each person costs per day/week/month x how long will they be employed (days/weeks/months). Using task hours is closer to that approach than using story points. – Amir Syafrudin Jun 15 '16 at 21:37
  • Adding a bit. It's already stated that you have six months to finish the project. Use that as the basis for cost estimation. Assuming the team is fixed, all you have to do is decide the costs of each person for 6 months. Voila! You've done your cost estimation. Well, at least you've done it for the human resource part. :) – Amir Syafrudin Jun 15 '16 at 21:46
1

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.

0

TL;DR

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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.