Archive for the ‘Estimation’ Category

Trailhead Estimate v0.2 Available

Friday, February 27th, 2009

The title pretty much says it all.? Head over to the download page and check it out.

This is an alpha version, about all I can say is it does work on my computer.? This was my initial interface prototype and now that I have a decent idea of how I want to improve it, I plan on throwing out most of the GUI code.

The first improvement is to make the task decomposition behave like the Outline mode in Word.? Essentially you would type the name of the task, hit enter, and it would create another task below it.? You could then use TAB/SHIFT-TAB to indent/outdent the task into a parent or child.? I also want to make the estimate time spans take actual times like “1 hour”, instead of the specific Timespan format.? Those 2 changes should make the interface much easier to use, and of course I also still have to implement alternatives, and I have been asked to add a few other features here and there (pretty exporting and actual time tracking being the 2 big ones).

All in all, still a lot of work to do, but it is nice to have something I can use in the meantime.

Posted in Estimation, Trailhead Estimations | Comments Off

Task Estimator v0.1 Alpha Screenshot

Tuesday, February 17th, 2009

This is my alpha interface, designed to flesh out any problems in the underlying design.? So far, everything is working as expected, but there are still some issues to work out:

image

You might notice that there is not currently a mechanism to specify alternatives.? The underlying model supports this, but the interface was proving problematic because of some custom displays I would need in the tree.? I will eventually want to wrap my own control to display it the way I want, but for now I just wanted to get something put together.? I hope to put the alpha version up on the site this week, so stay tuned.

Posted in Development, Estimation, General, Trailhead Estimations | Comments Off

Task Estimator Design Iteration #3

Friday, February 6th, 2009

This is my final design for this version:

I changed some things around added some methods, changed types, added other types, but the basic concept is still the same.? The code for for everything behind this is complete, so I need to finish off the serialization component and then throw together an interface.? If I can avoid having to travel, I should finish up in the next couple of days.

Posted in Design, Development, Estimation, Trailhead Estimations | Comments Off

Task Estimator Design Iteration #2

Monday, February 2nd, 2009

I've been trying to refine this design, and so here is the next iteration of the design.? I fleshed out some of the methods, fixed some of the connections, changed names of the items, etc., but the basic idea is still the same.? I don't like the way the Task and TaskItem classes are coupled together.? Ideally, I would like the TaskItem class to not need to know anything about the task class.? The problem that I am having right now is that TaskItem needs to account for the possibility of having subtasks that make up the item.? Since each of these subtasks might have an optional task item, they end up mapping back to Task:

I think at this point I'm just going to flesh out the underlying code and see how it turns out.? I should be able to stand up a prototype in a couple of hours, so I think it will be helpful to be able to see the design in action, and implementing it might jar some alternatives out of my current stupor.?

If you are curious, I separated out the UI and the storage code into different components from this one.? The idea here is that I'll be able to swap out either the Storage or UserInterface component independently.? This way I can iteratively refine specific aspects of the software without worrying about entangling myself in other components.? I will define specific public interfaces for the Storage component (and implement the factory pattern), so I can simply reference those interfaces instead of the specifics of a given implementation.? This Task component I am expecting to be pretty stable without any alternative implementations, so I don't see the need of making it easily interchangeable with a second implementation.

Posted in Design, Estimation, Trailhead Estimations | Comments Off

Task Estimator Design Iteration #1

Wednesday, January 28th, 2009

I've been forced to step away from this for the past several days because of work commitments with my real job, but I wanted to take a moment to throw up (pun intended) the first iteration of my design for the task estimator.? I don't actually like it at all, so expect to see further iterations coming soon.

I've left a number of things out – notably the serialization and GUI – but this is the core engine as it exists right now. Ugly, huh? This is about as far as I've had a chance to take the design so far due to other demands on my time, but I remain ever hopeful that my schedule will free up “in just another day or two”… Of course, it looks like I'll be traveling again next week, so maybe I'll have a chance to work on it then.

If you are interested, I have been working on the design in Visual Studio 2008's Class Designer tool.? It is very cool, and very helpful since it will automatically generate these classes for you.? Plus, with the addition of the Modeling Power Toy, you can export the image out as an image map, as I've done here.

If you are using Visual Studio and aren't using this tool yet, for shame!? All you need to do to get started is add a class diagram to a project.? Visual Studio will automatically analyze the project and create the diagram based on your existing code.? Of course, you can also start with an empty class diagram and do all your class design work from there.? That is what I'm currently doing.? I find that it is much easier to change my class design and structure when I am simply editing a diagram.? When I have to actually dig into the code to make these types of sweeping changes, I find it much more difficult to resist the code's inertia (things tend to be “good enough”)…

Posted in Best Practices, Design, Development, Estimation, Trailhead Estimations | Comments Off

Working on a few things

Thursday, January 15th, 2009

So I’m going to go dark for a few days here.? There are a couple of reasons – one is that I want to take the time to put together a first cut at the estimation tool.? Don’t worry, I’ll post the updates for everyone to see, but I want to set aside the next few days to iron out the details of the design and put together a mock-up of how I want it to work.

I have also decided that I need to generalize the Subversion Hook I wrote for work.? A few more situations have come up that are demanding a more flexible solution than I threw together the other night, so I’m going to work on a generic solution in my own time and post it on here when its complete.

So, I’ll be back on Monday or Tuesday, hopefully with some new goodies to play with.

Posted in Estimation, General, Subversion | Comments Off

So What Do My Estimates Look Like?

Monday, January 12th, 2009

Just to give you an idea of how I go about estimating things, here are my rough estimates for the 5 features I selected earlier.? You might notice that my estimates don't take into account everything I had listed in the features.? This was a conscious decision on my part to drop and or defer some functionality until later.? In the end, it goes back to wanting to keep the first iteration as small and nimble as possible.? That way I can adjust the tool to fit how I work iteratively – as I adapt to the tool, I can adapt the tool to what I want without worrying about large code changes.

Feature #1

I should be able to enter in a task, a length of time, and an indication of the range I think is possible
Total Time ~ 6 hours
  • Create Task class (2 hours total)
    • Create Data Members (1 hour)
      • Contains estimate in hours
      • Contains task name
      • Contains low/high estimate in hours
      • Contains list of child tasks
    • Create Methods (1 hour)
      • Adjust name
      • Adjust estimate with low and high estimates
  • Create Task Editor (4 hours total)
    • Enter new task (1 hour)
    • Edit existing task's name (1 hour)
    • Edit estimate in hours(1 hour)
    • Edit low/high estimate as percentage [0-100]. (1 hour)

Feature #2

I should be able to create child tasks.
Total Time ~ 7 hours
  • Update Task class (3 hours total)
    • Add Child Tasks (1 hour)
    • Add methods to add/remove a child (1 hour)
    • Add methods to automatically update estimates (1 hour)
  • Display child tasks in editor (4 hours total)
    • Display with name, estimate, and range (2 hours)
    • Add new children (1 hour)
    • Remove children (1 hour)

Feature #3

I should be able to specify alternatives/options for a given task.
Total Time ~ 11 hours
  • Update Task class (2 hours total)
    • Add Alternative Tasks (1 hour)
    • Add methods to add/remove alternates (1 hour)
  • Update Task editor (9 hours total)
    • Display Alternatives (3 hours total)
      • Display name, estimate and range (1 hour)
      • Add new alternative (1 hour)
      • Remove alternative (1 hour)
    • Select/Activate Alternate (4 hours)
    • Modify Display to indicate alternatives (2 hours)

Feature #4

I should be able to enter multiple estimates/ranges for a given task.
Total Time ~ 13 hours
  • Update Task Class (9 hours total)
    • Allow for multiple estimates and ranges (2 hours)
    • Adjust methods to specify specific estimate being edited (2 hours)
    • Update to indicate “active” estimate. (1 hour)
    • Update estimate calculation (4 hours total)
      • Account for only active estimates (1 hour)
      • Take mean/median of estimates (1 hour)
      • Take high/low estimate (1 hour)
      • Specify which algorithm to use (1 hour)
  • Adjust Task Editor (4 hours total)
    • Add indication of multiple estimates (1 hour)
    • Add ability to select estimate calculation algorithm (3 hours total)
      • Select algorithm (1 hour)
      • Add ability to select specific – active – estimate (2 hours)

Feature #5

The estimate should be saved in a human-readable format
Total Time ~ 8 hours
  • Define an XML schema (4 hours)
    • Hierarchically based on tasks
  • Serialize Task class to/from schema ( 4 hours)

That is the basic outline.? Right now I am looking at an implementation time of roughly 45 hours.? Everything is very rough at the moment because I am still in the design stage, but that is a pretty good start for the moment.

I should also point out that I have a minimum task time of 1 hour.? Since these estimates are composed of fairly small and granular tasks, these estimates may have been skewed upwards.? I think that skew will be balanced by the current uncertainty in the design, but we shall see.

Posted in Estimation, General, Trailhead Estimations | Comments Off

Setting Priorities

Saturday, January 10th, 2009

Now that I have my (very) basic feature list, I can very quickly determine what I think the risk would be if not implemented:

  1. I should be able to enter in a task, a length of time, and an indication of the range I think is possible. (High-Risk)?
  2. I should be able to create child tasks. (High-Risk)
  3. I should be able to specify alternatives/options for a given task. (Medium-Risk)
  4. I should be able to enter multiple estimates/ranges for a given task. (Medium-Risk)
  5. The estimate should be saved in a human-readable format. (High-Risk)

Since my feature list is so small, pretty much everything falls on the upper-scale of implementation risk.? Obviously, features #1 and #2 are critical to the tool.? If I can't create and break down tasks, it is nearly impossible to estimate them with any accuracy.? Features #3 and #4 I could get away with skipping, but I consider those to be the differentiating factors from how I currently create estimates.? Without those features, I see little value in changing my ways.? Finally feature #5 was considered critical because my estimates won't do me any good if no one else can read them.? Keeping them in some hard-to-read format would make the tool essentially pointless since the purpose of estimates is to share them with someone else (whether it is other developers, your boss, or your client).? I am assuming that most people will not have any interest in installing this tool simply to view an estimate, so without this feature the whole thing becomes an exercise in pointlessness.

Given this list, I'm going to start by breaking down features 1,2, and 5 into a complete estimate.? After I'm done, I'll specify features 3 and 4.? That should give me an idea of how long this whole endeavor should take.

Posted in Estimation, General, Trailhead Estimations | Comments Off

Feature Poor

Friday, January 9th, 2009

Yesterday I talked about what I needed in a new tool I wanted to use to create task estimates:

  • A tool to create and share estimates.?
  • Different people should be able to collaborate on these estimates.

Obviously these were very high-level goals for what I needed to accomplish.? There are some things I want to point out though.? The first is that these requirements make no assumption about a possible solution – that is what I am going to define today.? I also want to point out that I can already do all of these things using my current process (Powerpoint slides and email).? I just don't like it.? So today I'm going to outline the basic feature set I want.

  1. I should be able to enter in a task, a length of time, and an indication of the range I think is possible
    1. Range could be in either hours or a simple percentage of the estimate.
    2. It may be necessary to enter different values for the low and high range.
  2. I should be able to create child tasks
    1. The parent will automatically calculate the estimate based on a summation of the children
    2. The parent should also automatically calculate the range.
  3. I should be able to specify alternatives/options for a given task.
    1. The option should be treated just like a regular task
    2. Only one of the alternatives can be “selected” at a time
    3. All parent tasks must indicate the presence of options in their estimates.
  4. I should be able to enter multiple estimates/ranges for a given task.
    1. The actual estimate should be calculated in a user-specified mechanism
      1. Mean/Median
      2. High/Low Estimate
      3. “Consensus”
    2. I should be able to control which estimates are visible
  5. The estimate should be saved in a human-readable format
    1. I should be able to, lacking any other option, open the estimate in Notepad or an equivalent and edit/view the estimate.
    2. The format should be easy to transform into a format consumable by other programs.

That is pretty much the basic feature list.? I left out a number of items from my normal template (including the problem description and possible solutions).? This should give me enough functionality to get started and figure out what works and what doesn't.? No sense in re-inventing what I already do when my goal is to improve it, so for now I just want the most basic functionality I can get away with.? I can always refine and add features later.?

So now that I have my target features, my next step is to prioritize and then estimate these features.?

I guess its back to Powerpoint for now…

Posted in Estimation, General, Trailhead Estimations | Comments Off

Scratching My Own Itch

Thursday, January 8th, 2009

I need a new tool.

You see, I am a firm believer in the value of software estimation.? Estimating out a feature or problem helps me to focus on what specifically is needed to implement it.? It avoids problems where I can't do everything I want to do because I run out of time.? Most importantly, it gives me some sense of the relative cost of any feature.

For whatever reason, I have traditionally always done these estimates in Powerpoint.? I have a pretty stable template that I follow for each estimate:

  1. Define the Problem.
  2. Overview of possible solutions (including non-code solutions).
  3. Recommendation of solution.
  4. Estimate for solution
    1. Include estimates for alternatives and options for implementation.
    2. Include estimate of “risk” – possibility of a given item taking shorter or longer than estimated.
  5. Total time
    1. Actual Estimate.
    2. Worst-Case Estimate (assumes all the longer risk estimates).
    3. Integration Time.
    4. Estimated Testing time.

I do these estimates for most every feature I am assigned.? Normally, no one else takes notice.? I send them out to my manager and he creates his schedule, and everyone else just goes along.

However, we have been having trouble meeting our release dates because features keep taking longer than expected.? Having noticed this, it was decided that the entire team should begin estimating out features in much the same manner that I do.? So now we have around 8 people creating these estimates in whatever form and format they want.

Needless to say, integrating all that information is beginning to become a problem.

In addition, we have a number of younger developers.? They do not have much experience in creating these types of estimates, so it is desired to have a more senior developer work with them on their estimates to ensure their accuracy.

That is also very difficult when everyone is creating these items ad-hoc.

So that is my problem.? At the very minimum I need to meet these requirements:

  • A tool to create and share estimates.?
  • Different people should be able to collaborate on these estimates.

I'll let you know how it turns out…

Posted in Development, Estimation, Trailhead Estimations | Comments Off