|
1
1
|
This is comment in the workflow plugin that is near one of categories (Scheduled items, i believe). What does it mean, what's special about this category? upd: still, I wasn't able to understand this. Does anyone feel a need for better EBS docs? upd 2: let me rephrase the question. Why can't i delete this type of task? What's so special about it? |
|||||||||||
|
closed as exact duplicate by Rich Armstrong♦♦ Sep 19 at 19:31 |
|
0
|
Does this post not answer your question? http://fogbugz.stackexchange.com/questions/1012/whats-a-schedule-item |
|||||||||
|
|
0
|
Hi Alexander, The best post on EBS that I've found was the one that Rich wrote. http://fogbugz.stackexchange.com/questions/4396/evidenced-based-scheduling-ebs More to the point however, a Scheduling Item is a case that is the member of the Scheduling Item category, and it is essentially a case that does not affect EBS (but it does effect your availability with respect to scheduling). Said another way, if you had an absolute law at your place of employment that 8 hours of work MUST be logged, you may spend 6 hours programming, and 2 hours doing Scheduling Item tasks like meetings, answering phone calls, etc. Alternatively, let's suppose that you have a super-relaxed employer with respect to logged time, but they get really angry when deadlines are missed. Well, if you knew you'd be in meetings for a good part of the day, one day, you may just want to make a scheduling item case for that. PRACTICAL EXAMPLE To take the description in a different direction, the whole purpose of EBS is simply to give project managers a line of sight into the expected deliverable dates, or to give project managers the ability to time-box a release, and limit the features so that 100% of deadlines are met. With that in mind, FogBugz assumes, by default, that you're working an 8-hour day. You can adjust this in your scheduling settings, but let's just go with the 8-hour mark for now. If you have lots of EBS cases that have been estimated, time tracked, and ultimately closed, FogBugz has a velocity for your programming speed. For the sake of argument, let's call that velocity 1.3, meaning that when you estimate 8 hours worth of work, it really just takes you 6.15 hours of effort. SO, if you estimate a project's story cases to take 40 hours, you should be wrapped up in about 30.77 developer hours. However, that's not inherently to say that you have 30.77 hours available in your work week! Let's say that in your instance, you have your Site Working Schedule set to 75% of your time on this project (Acme Widget), and 25% of your time set to all other FogBugz tasks (your other obligations and projects). That adds up to 30 hours of your 40 hour work week on the Acme Widget project, and 10 hours of your 40 hour work week on other stuff. We're only concerned with the 30 hours for now. According to the model above, your project manager should be okay to think that you'll be done with the Acme Widget in 6 work days, since you work 6 hours per day on Acme Widget, and you only REALLY estimated 30.77 total developer hours. BUT WAIT!!! What happens if you have 10 more hours worth of Scheduling Item cases (via your estimates) assigned to the Acme Widget project? Well, you certainly won't be done in 6 business days, because your new amount of available time during the first week is just 20 hours for the Acme Widgets project (as 10 hours go to the scheduling items, and 10 hours goes to your other projects). In other words, scheduling items are assumed to be a 1:1 ratio of estimate to velocity, because scheduling cases are assumed to be really repetitive tasks, and not things that may be done earlier or later depending on the quality of your estimate. DISCLAIMER All that said, I'm certainly not a FogBugz employee, and may assertions should be validated by the community. I think I'm correct, but I am not 100% certain (despite how confident the post sounds). I hope this helps!! -Ryan |
|||
|
