ebs Questions - FogBugz Knowledge Exchange

Feature Request: Ability to set a completion date on a milestone which depends on another that has no date

2011-06-17T15:43:34Z

When I setup these milestones:

Prep Work (no date)
Coding (no date, depends on Prep Work)
Testing and Release (no date, depends on Coding)

and I then try to set a completion date for Testing and Release, FogBugz won't let me, complaining that it starts before a milestone which it depends upon.

What's going on?? Answer: FogBugz always assumes that milestones with dates come before ones with no dates.

Feature Request

If there are dependencies involved, as in my case, EBS should be smart about it and see that the one with a date must come after those without dates, and allow me to set it that way.

Case FC2077466

Resolve / close a case with incomplete time tracking

2011-06-09T11:31:04Z

I forgot to track my time on a feature over a long time. Now I am done with the feature and would like to close it but the estimate should not be counted as it would be grossly inaccurate. How can I do this?

Evidence Based Scheduling: Weighted Area

2012-01-17T08:19:26Z

The EBS is a really cool tool, which helps us to get better estimations for releases.

But there's one fact that seems to be ignored by EBS .

Depending on the Area the simulation should be weighted. For example, when estimating a feature, like "adding some properties to the viewmodel" is much easier and exacter than estimating some other features like "adding undocumented legacy com component".

So perhaps EBS should more weight existing estimations in same areas. So a prediction for a task related to viewmodels should be more based on other viewmodel tasks and not the com task.

Any opinions about this ?

Many Thanks in advance

Best way to do estimates for pair programming

2011-12-13T22:39:25Z

I was wondering how estimates and estimates-based-scheduling should work when you have some cases that are worked on using pair programming.

Only one person can estimate but if both people are creating timesheets working on the case, this will effect the estimate history for the person that created the estimate.

Here's a couple specific questions:

Would it be best to remove these from the estimation history?
If a team uses pair programming for all their cases, should the pairs try to take turns with who is responsible for entering the estimate?
Does anyone have any better ideas I'm not thinking of based on actual experience using FogBugz in a pair programming environment?

How to Estimate Software Tasks

2010-09-15T19:24:51Z

What are your best practices for estimating software tasks?

Case status for completed but not yet deployed features.

2011-10-12T18:48:28Z

I am trying to integrate FogBugz into our agile development process and am hitting a roadblock. We use Feature cases as User Stories. These get estimated by the team in a planning meeting and the estimates entered by a single person. As the features get completed the cases get marked resolved. When the feature gets deployed (in a release) the "Version Fixed" field gets updated with the release number and the feature is 'Closed'.

Here is my problem: EBS only seems to work when the cases get 'closed', so to track progress we have to close the cases.

When a case is closed, the "Version Fixed" field is no longer editable, so we either need to know the version the feature will be released in before closing it, or re-open the case to add it once we know it.

Am I missing something? Is there a better way to handle this?

Allow Project Manager to Enter Developer's Estimate But Count Against Developer's EBS

2011-06-02T18:28:30Z

I understand that EBS is counting the user who last entered an estimate for a given case before time is applied.

Our PM's start with a task list that the Dev's estimate (on paper or verbally in a meeting), and then the PM builds out the project structure in FogBugz (the Dev can always edit and add cases, but the primary list was reviewed and agreed upon by the Dev and the PM). However, short of logging into each user's account in FogBugz to apply the estimate that they did indeed provide to the PM, or creating a custom field to track this estimate forcing ther Dev to populate a redundant field, a PM cannot currently enter an estimate on behalf of a Dev so that EBS is used with the Dev and not the PM. The potential solution of creating a virtual user that gets hit with the EBS isn't quite right here - it's that Dev's estimate.

I suggest that it go something like this: Given FB doesn't do this, my guess is that it's because FC feels it's important that the person who works on the case acknowledge that the estimate is his/hers. However, the PM can enter an estimate, and then the Dev can change it before starting work to make it count towards the Dev's EBS, and that's actually more confusing than it probably needs to be.

Once a case has time applied, a user should be given an option of confirming the existing estimate (whether in timesheet/interval or edit case on save) and that it is their own. Alternately (and preferred), a user entering a case for a different Normal User (not virtual) with an estimate defaults to have EBS affect the user assigned. A user can always change it if they want and the same rule applies where last user changing an estimate gets EBS to count against their history, but the modification would add a checkbox (defaults in prefs) that if checked, counts the user assigned, if unchecked, counts the user who is editing.

It doesn't make a lot of sense to me that a PM can enter an estimate on behalf of the Dev, but for this to work, the Dev currently has to change the estimate to something else, then change it back to the original as a workaround. Something should shortcut this process.

I have reviewed this with FB support to confirm it's a new request.

Thanks for listening!

How do I represent a user who works on multiple projects?

2011-04-14T12:48:19Z

Hi Folks If I want to allow the people in my team to work on several projects which are running concurrently, how do I get accurate completion date estimates for each project? The problem is that each project would seem to be calculated in isolation, assuming that each contributor is working on just that project. Many thanks Paul

Feature Request: Add a measurement of velocity (for each user) to the FogBugz API

2011-09-19T19:28:28Z

We want to be able to use the API to calculate resource availability, and the way that we'd like to do this is by adding up the remaining time for all cases a user has assigned to them, multiplying it by that user's velocity, and then dividing by the number of hours per day that they work on FogBugz tasks.

I think we can do all of this except for the velocity part :(

Why doesn't FogBugz offer Gantt charts?

2009-12-10T22:18:29Z

My manager knows how to read a Gantt chart and can make sense of them. Why doesn't FogBugz have them?

Evidenced-Based Scheduling (EBS)

2010-09-07T17:46:33Z

Can you please give us an overview of Evidenced-Based Scheduling (EBS)?

What is EBS Scheduling item category?

2011-07-20T09:52:37Z

Possible Duplicate:
Feature Request: Allow deletion of the schedule item category

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?

Feature Request: Change how % time allocation works

2010-02-10T04:24:48Z

FogBugz gets a lot of stuff right:

It doesn't just accept my estimate. It looks at my history and gives me dates based on what I've done - not what I say.
It doesn't just accept the team's estimate for the hours in the burn down chart. It ingeniously brings probability into the mix there as well.

So why does it just accept my estimate for how much time I'm going to spend on a project? This just completely undoes all of the good stuff.

I guess there are some people that work exactly the listed percentages on each project but I've never seen that. I can't tell if a task is really going to take 2 hours, I certainly can't tell if I'm going to be working on projectx for 90% or 80% of my time this week - I can estimate, but I can't know.

There has to be a way for FB to look at my past and figure out the following:

How much time am I actually spending on projectx vs my estimated allocation?
How much time will I probably spend on projectx in the future vs my estimated allocation?

I think FB should never accept our estimates as-is.

To take this one step further, actual vs estimated time should be shown somewhere. Possibly in an existing report or in a new report. This is really important for project managers who need to understand what's happening on a project. It also helps people adjust when they're not working at the right allocations. They can either switch gears to focus on a different project, or work with their managers to change their allocations.

Also, it seems like this would tie in very naturally to how all of the other reports are working.

Case FC1303047

How can we track EBS for QA testers if they are part of the story workflow?

2011-08-28T20:21:23Z

I'm not currently having our QA testers track time in FogBugz out of the fear that it will throw off EBS, but I hate this. Is my fear well-placed, or totally unfounded? We're a professional services company, so this is certainly a point that effects us quite directly. Please advise.

Here's the workflow we have today for stories:

Active

1. Not Started [Default status for active cases] <-- Assigned to developer
2. In Progress <-- No assignment change
3. Ready for QA on Staging <-- Assigned to QA tester
4. Verified by QA on Staging <-- Assigned to project manager (AM)
5. Ready for Client UAT <-- Assigned to account manager
6. Ready for Production <-- Assigned back to developer for deployment

Resolved

Resolved (Verified on Production) [Default status for resolved cases] <-- Assigned back to PM
No Action (Already Implemented) <-- Assigned back to case opener
No Action (Duplicate) [Duplicate case status] <-- Assigned back to case opener
Out of Scope (Works as Designed) <-- Assigned back to case opener

Feature Request: Add a date filter to the burndown chart report

2010-10-21T08:49:43Z

They way I've been using FobBugz is to plan out a bunch of releases (usually one every 2 weeks or so). So, for example, you might have the following releases/milestones in the Inbox project:

Unassigned
Release 10.1 (due date 15 Jan)
Release 10.2 (due date 29 Jan)
Backlog - accepted but not yet scheduled

As change requests come in they generally go into Unassigned.

After each release I usually have a conversation with the major stakeholder (who's not really a coder) concerning priorities and we discuss which of the new change requests we actually want to implement and, specifically, what we want to attack most urgently (in the next release).

During a release cycle, sometimes priorities shift a little, some things get prioritised and some things get bumped out to the next iteration to ensure the release is made on time.

This works well, but if you schedule in some milestones/releases 2 months in advance, by the time you actually start working on the milestone there is already quite a bit of history in the burndown chart (typically an almost horizontal line dating back for months). If you only work on the release for 2 weeks (which is typical in our shop) or 1 week (typical in other shops) then by in large the burndown chart is going to be uninteresting noise... a horizontal line for 2 months and then finally 1-2 weeks of actual work where the burndown chart creeps down towards zero.

There are a couple of ways that this could be avoided.

One would be for me, before each release, to create a new milestone and transfer over all the stuff from the old one to the new/real one... then delete the old one. This would work but it's not really how I'd like to work with the software.
A second option would be to have some kind of "Start Date" on the milestone which could perhaps, by default, be when work was first started on one of the cases in the milestone. My thinking is that the burndown chart could only show data from the start date onward.
A third option, similar to the above, might not be to have any particular field but at least allow the user generating burndown charts/reports to specify a date filter for the report... that way I could (knowing we only started work on that milestone on the 5th Oct) say "only show datapoints from Oct 5 onwards.

Does the above make sense?

Cheers, James

Case FC1963797

Feature Request: Burn-down chart without EBS adjustments

2011-07-18T08:52:24Z

The EBS Burn-down chart shows you the adjusted (predicted) hours remaining. Please create a version without EBS.

The menu Schedules > {project} > Burn-down chart (no EBS)

REASON I am a FogBugz consultant and I spend alot of time putting in new installations for customers. EBS is a difficult concept to put across in the short time I have to do the installation. It also returns useless data until after the first few sprints.

A simple burn-down chart with no EBS would provide a stepping stone to using EBS. It would also demonstrate the superiority of EBS.

Case FC1870724

Best practice for "Testing Time"

2011-04-21T22:28:40Z

When we create a new project and add the tasks, we usually add two weeks of time at the end just for additional testing and bug checking. What we'd like to do is add these as a new task so the reports include these two weeks of hours.

What turns out happening is FogBugz will treat is a a regular case and adjust the time it expects us to do the testing for and not keep it as two weeks.

I've tried this with all of the categories and none of them seem to keep my original two weeks estimate. (oddly enough, I tried a schedule item and it added four months to the project even though I typed in two weeks).

Any ideas what I might be doing wrong or what I could do to get the result I'm expecting?

Feature request: an option to tell EBS to take unestimated cases into account

2009-12-31T06:04:56Z

The main question is here.

Okey, as recommended, i've learned to divide tasks by 3-8 hours length. I have a group estimation process.

So now i'm entering new tasks and trying to do some rough date planning on that data.

I don't want to estimate tasks by myself, because i want the team (or concrete devs) to have final estimates so they can learn to estimate and because fogbugz uses only original estimate for all the real things.

I want EBS to take unestimated tasks with some reasonable historic averages (monte-carlo on historic data would do greate, i think) and produce me rough planned dates.

I guess that could be done with a "simple" checkbox on reports page.

Case FC1836751

Using FogBugz for planning of many projects

2011-04-04T09:12:35Z

We're trying to use FogBugz for long term planning of many projects. Our goal is to assign tasks to iterations (we have iterations lasting 1 month, they can be understood as sprints in scrum methodology) in such a way every projects completes in time. At the time of long-term planning we don't want to assign tasks to particular persons - we'd rather like to substitute each team with a virtual user whose productivity is equal to team productivity. Then we'd like to use charts (Per-user timelines, Completion date) to see if project milestones could be reached.

Similar topic was discussed in http://fogbugz.stackexchange.com/questions/1200/how-does-ebs-work-with-virtual-users. Chris Phillips suggested super virtual users with >100% time allocation. We also think such feature would be very useful for planning.

The question for now: What would happen if we manually edited FogBugz database and change the field nPercentTimeAllOtherProjects in WorkingSchedule table to i.e. 500 for virtual user to simulate a super-user who works as hard as 5 regular users ;-) ?

What causes an user/a case to be blocked?

2010-03-18T10:48:32Z

On the global milestones report, when you view per-user timelines, the legend shows it's possible for an user (or a case?) to be blocked.

When does this happen?

Can an administrator set vacation dates for other users?

2010-04-26T18:21:16Z

As a manager and FogBugz site admin, can I setup vacation time for my team members?

Case FC1888023

Does FogBugz support task dependencies?

2009-12-17T03:48:07Z

FogBugz seems like a nice way to have to views on the same database: one for engineers and one for project managers. This way new tasks (i.e., bugs) added to the bug tracker automatically show up on the project plan, thus minimizing the effort in keeping things in sync. However, searching the various databases and playing with the trial fogbugz on demand led to a dead-end regarding one critical feature: how to set up task dependencies.

With this, I could see how to use it as a replacement for a Gantt chart. Without it, I don't see how to properly set priorities / determine the critical paths.

Feature Request: Facilitate "What if?" scenarios in EBS

2011-06-17T15:20:12Z

EBS allows me to look at ship date predictions for the Projects, Milestones and Priorities I want. I need to do a lot of "what if?" scenarios to manage my projects. The way I have been doing this is to edit the priorities on cases to set them to a higher level and show the graphs for a lower level in EBS. This works, but it means that my developers receive lots of emails for the case edits, and might even work on the wrong case based on temporary priorities.

Feature Request: allow me to show EBS reports for any filter/search of cases.

Case FC2043420

How can I get EBS predictions for different scenarios of individual cases to help me order my backlog?

2010-08-24T00:40:34Z

Happy Monday all,

I'm currently trying to create some project complete forecasts based on what cases we decide to address before final. I'm looking for a plugin or script that will quickly allow me determine project end dates based what cases we decide to address.

Anyone know of a plugin, tool, script, etc. that will help facilitate that? It's kind of like creating reports on the fly using varying conditions.

Thanks, EZ

Do developers need to track 100% of their time for EBS to work?

2011-04-14T12:12:09Z

Ok, so I think I know the answer to this, but I'd like some confirmation... Our developers are working on one (big) project. We've estimated a lot of stuff into FogBugz, and we're now working through it. One of the observations I have is that currently the developers aren't recording meetings/email/etc in any form in FogBugz, so they typically record (say) about 5.5 hours a day rather than 8.

My assumption is that FogBugz has no way of coping with this automatically. I believe I have 3 options:

Get the developers to record this time against the task they were last working on, and allow EBS to extend the schedule accordingly (this seems the best option to me). Requires policing to ensure that people are recording ~8hrs of time each day.
Create schedule items for meetings etc for each developer to try and allow for this extra time. Error in these estimates will be factored into EBS but it's a pretty arduous way of tracking this stuff and it's likely to have a much higher error rate than normal estimates which will skew EBS generally.
Attempt to work out how much time we spend in meetings and adjust the % of time spent on FogBugz cases accordingly. The simplest method AFAICT, requires least effort from the developers, but doesn't take advantage of EBS to keep track of the reality. If it changes everyone needs to go and adjust their % time manually as well (zzzz).

Have I missed another way of doing this? What do people think is the best approach?

Lucian

How do I retrieve the adjusted hour value for a given milestone?

2011-05-27T12:30:43Z

Assuming EBS is trained well with recent data, and a team estimates each case for a given milestone, which report can provide me with the adjusted number of hours of work? This should not consider other milestones and work since I want to be able to use this for costing purposes. For example, the adjusted hours should not apply working schedule etc.

Can I safely use the 'Burn Down Chart (this milestone only)' report? I don't currently have enough data to make sense of the reports. What probability threshold is used to calculate hours remaining?

As an example: If a team estimates 10 cases and the sum of the estimated hours is 100 hours. I would like to know how many actual hours (not time) will be required to complete the work. If each member of the team always overestimates by a factor of 2, then the report should return 200 hours.

I hope this makes sense.

The remaining hours in my burn-down chart is much more than I expect

2010-09-17T17:57:05Z

Is there a formula that you could share? Is it based only upon hours or does it required a special status?

We have a project that for days only shows 8 hours as "remaining hours" but the burn down chart still shows hundreds of hours left. How do we get the burn down to show 8 hours?

Feature Request: Group Cases for EBS

2010-02-10T05:34:22Z

Problem

I understand that the best way to use EBS is to always re-open your case whenever you find a bug or have to do rework, and continue putting time in against that original case until the task is finally and undeniably completed.

However, this doesn't work for us. We want to open and track bugs against the code we're writing. This provides a lot of value to us. - The problem is that new cases opened for these bugs don't count against the original estimate for EBS.

Scenario

Developer opens a task to "code foo" and puts in an estimate of 10 hours.
- Developer's estimation history is perfect. His variance from the estimate is 0%
Developer takes exactly 10 hours to "code foo", resolves and closes his case.
Tester tests foo and finds a bug. Tester opens a case for Developer to fix the bug (note that Developer could just open a new case, or any other method you could think of for generating a new case)
Developer estimates that the case to "fix foo" will take five hours.
Developer takes exactly 5 hours to "fix foo." He resolves and closes the case.
- Developer's estimation history is still perfect. His variance from his estimate is still 0%.
- The reality is that Developer was off by 50%! How do we show this without losing the value of opening a case for each bug found against the delivered code?

Proposal

My suggestion is to allow cases to be related to each other for the purposes of EBS. It could be the same level of user effort as entering a parent:

Have a field called something like "Original Case"
- This would have functionality like the parent/subcase fields where it would provide narrowed results while typing.
Have all of the elapsed time from those cases count against the original estimate of whatever is entered into the the "Original Case" field.
Have any case that points to an "Original Case" not count against EBS as the results may become skewed otherwise.

This allows us to capture valuable metrics such as how many bugs did we generate while writing each feature. Meanwhile, it also allows us to have really good EBS.

Case FC1856365

How does EBS works with not estimated tasks?

2009-12-30T06:48:59Z

Does it take the into account at all?

Does it take some average (random?) task length estimate for them?

Does it take some average (random?) real task length?

Please note, that this tasks are mainly assigned to 'up for grabs' virtual user.

Case FC1865640

EBS and interruptions

2011-05-11T20:06:02Z

I've been doing a fair amount of reading on the FogBugz EBS feature, however, I'm still a bit confused with respect to a strategy for handling the way we work.

Our team works on various projects which can be broken down into two categories. The first is your usual software project, work is broken into milestones/sprints which the team tackle sequentially. The second category encompasses support type projects where we expect a certain amount of time each month to be spent on support tasks. Support cases are created as issues arise and the team tackle them when they need to (high priority means dropping what they are doing while lower priority tasks are tackled when a natural break occurs). Time spent on support tasks are billed for and customers expect time sheets.

I understand how EBS works for projects in the first category. If the team was only involved in these types of project then they could keep the clock ticking when disruptions occur. The EBS algorithm would naturally project probabilities based on previous evidence and I can see how that could work quite well. The problem is that the team are often interrupted by these support tasks which need to be tracked in terms of time. Team members cannot just leave the clock running on the project work case, they need to switch tasks and track time on the support item.

The issue now becomes that the EBS algorithm will not take these ad-hoc support cases into account when calculating probability for hitting a project milestone. How can we make this work? I have an approach that I think may work and wouldn't mind if someone familiar with FogBugz could comment.

Setup support projects with a workflow that disables EBS tracking.
Configure category 1 projects with a workflow with EBS tracking enabled.
Configure %time allocation for each developer based on previous reports outlining how much time is spent on support items per month on average.

When a support task interrupts a developer, the developer needs to stop the time tracking on the project case. The developer then switches to the support task and tracks their time spent on the support item. If a disruption occurs during a support task, the developer has to treat the interruption differently to a project case item since the customer is paying for time spent on their item. This time has to be allocated back to the project task. As per normal, if a disruption occurs during a project task, the developer can leaving the clock running.

The process is onerous, but I can't think of any other way of handling this process.

EDIT:

I realise that category 2 projects don't require that EBS be turned off since the percentage breakdown of employee focus can be managed, it wouldn't make sense to disable EBS for support tasks that do have an estimate.

Further to my questions above, I need to understand how our team can facilitate planning. Right now, it doesn't look like there is one place to review all upcoming milestones and their expected completion dates. It seems like you need to iterate through each project and review milestones there which is annoying. As far as I can tell, you also cannot create a report which lists all milestones due in an upcoming period (the next month for example). I don't see a search axis for milestone date, this seems a little bit ridiculous?

Also, as a project manager, where can I review my team's estimation history? I see there is an option to review my estimation history, but that doesn't really help. Given that interruptions will always occur, I need to understand the impact on estimation as the overhead in developing software needs to be reflected in the costing process. How can I do this?

Any thoughts?

Rohland