I'm having trouble seeing the benefit of setting the Activity field on Tasks for use in Capacity Planning (I'm using the Scrum Template). In fact, doing so seems to make things more cumbersome.

Why would I want to try to balance out my time between Requirements, Design, Development, etc.? I would think that the actual task to be performed should drive things, not the type of work that it is. All I end up doing is adjusting the Capacity Per Day during my Sprint planning so that nothing sits in the red. Just that alone invalidates the feature, at least in my case.

In all of the Capacity Planning examples I've seen so far, each team member is assigned a single Activity. I can see where Activities can be helpful here, as a means to know when a team member might need assistance from someone who might be a bit ahead of schedule.

For teams, sure. But for a solo developer I can't see it.

Can somebody show me where I might be mistaken in this? What can Activity tracking do for me besides make my life more difficult?


To clarify, I'm speaking of the use of the Activity field in the context of Capacity Planning (CP) only. Setting the Activity field on Tasks for use in later reporting I'm okay with—in fact I'd prefer to. But for CP it's a different story.

For example, consider this plan:

Capacity Plan by Activity

There's just a whole lot of detail in those CPD fields that seems unnecessary. After I select my tasks for the sprint—based on priority and effort—all I end up doing is fudging the numbers until the graphs at the right (appearing underneath in the graphic above) don't show red anymore.

It seems a futile exercise. My argument is that the work to be performed should drive task selection, not the type of work. Especially since by the time I get to this part I've already selected the tasks anyway.

Yes, it's true... a large part of the motivation behind my recent adoption of TFS is wrapped up in my own tendencies to underestimate terribly. In fact one of my customers tells me "Nobody can underestimate you, Jeff."

But in thinking back, my underestimations have been task-based, not type of work-based.

What will I be missing, should I leave the Activity field empty on the CP tab and simply set my individual capacity to the number of hours I expect to work each day?


2 Answers 2


For us, it is just a drill down category for reporting. They save having to wade thru the task description to find out what sort of activity it is.

If nobody has eyes on your sprints and aren't creating any sort of reports and the like then it can be tempting to ignore this but it really isn't that much extra work.

At a macro level they can be used as an acid test to determine the traction of the project. Some have analysis and requirements for the first few sprints and development after while others have a bit of everything in each sprint. It really depends on the project.

  • Oh yes... for later reporting, absolutely! I think it'll be extremely valuable to look back and see how much time was spent on design, development, testing, etc. What I'm having trouble reconciling is have to spending so much time 'balancing out' the various Activities on the Capacity Planning tab. See the graphic above in my edits. Do you agree?
    – InteXX
    Commented Apr 5, 2016 at 9:03
  • Ah, OK - though you might have been talking TFS but wasn't sure. Which version are you using as a matter of interest?
    – Robbie Dee
    Commented Apr 5, 2016 at 9:18
  • On-premises TFS 2015.1, about to update to 2015.2 in a couple of weeks or so. Are you on TFS/VSTS?
    – InteXX
    Commented Apr 5, 2016 at 9:37
  • We're on TFS 2013. I don't believe this has the functionality to breakdown activity beyond a sprint...
    – Robbie Dee
    Commented Apr 5, 2016 at 9:52
  • I see. Were you able to, would you tend to agree with me that breaking it down for Capacity Planning—as shown above—seems unnecessary? Or would you instead say, "Hey Jeff, better get with it, you're about to shoot yourself in the foot here!"
    – InteXX
    Commented Apr 5, 2016 at 9:56

As a fellow lone developer, it's difficult to see the need for a lot of things that are more beneficial for a team especially in areas of communication and documentation of time.

How much do you want to fine-tune your estimation skills. You may find out there are areas you're not considering (e.g. deployment) or you may underestimate or overestimate some areas. My experience is that teams seem to get sucked into spending too much unproductive time on design, so it's important to watch the clock and try to stay on topic. Lone developers run the risk of not setting enough time for design.

Growing your team. Ideally in Scrum, you would add another team member that does everything just like you, but you may find a situation where only part-time help or a consultant is all you're going to get.

  • I VERY MUCH want to fine-tune my estimation skills—in fact desperately so. But that strikes me as something that's best done at the Task creation stage, when breaking the job down into bite-sized pieces and taking an educate guess at the Remaining Hours for a new Task. Wouldn't you agree? (All that said, now that you mention it I find I must admit to a habit of diving right into a project and not spending enough time on design. So you nailed it there.)
    – InteXX
    Commented Apr 5, 2016 at 9:08
  • 1
    @InteXX While the activity types may seem to finely grained for a solo developer (I am one for my spare time projects), fine tuning your estimation skills requires knowing what you spend your time on and what causes over runs and under runs of your estimates. Having finely grained estimates may not be much help, but having recording the time you spent on an item by activity may well help you understand where (and for which type of items) you need to adjust your "first impression" estimates. Commented Apr 7, 2016 at 9:28
  • @MarjanVenema: For example, here's what I'll do. Let's say I have to build a new web page to capture some contact data. I'll think about it a moment or so and then proudly announce to myself: "Shucks, I can toss that together in a couple hours." Well, guess what... four hours later I'm still plugging away. That pretty well sums up the flow of my underestimation. So I must have a mental block—I'm still not able to see how breaking a Sprint into multiple Activities during Capacity Planning can help solve this.
    – InteXX
    Commented Apr 8, 2016 at 3:35
  • 1
    @InteXX: just make a list of everything you need to do to make this thing. Eg.code the html form, wire it up, do the table to store the data, set up the orm mapping, test the validation and database logic, etc. etc. Such a lists serves as a todo / check list for when you actually start the work. More importantly, it will serve as a reality check against your initial "4 hours" estimate. Just listing what needs to be done will give you a better feel for the work involved. And that's also what the activities split in estimates is intended to do: most developers forget about the qa/testing work... Commented Apr 9, 2016 at 9:38
  • @MarjanVenema: OK, I'm a little closer now. That helps. I'll continue to use it for the time being and see how it all settles in. Thanks.
    – InteXX
    Commented Apr 9, 2016 at 20:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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