Frage

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?

EDIT:

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?

War es hilfreich?

Lösung

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.

Andere Tipps

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.

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top