How granular should an estimate be for building a web page?

Question

Sufficient Granularity?

I have a ASP.NET web page to construct. The design of the UI and classes is already complete. I have prepared a task breakdown, including hours needed for each task.

Does this WBS need to be split up further to be sufficiently granular?

Work Breakdown in Hours

╔══════════════════════════════════════════════╦═══════╗
║                     Task                     ║ Hours ║
╠══════════════════════════════════════════════╬═══════╣
║ SQL formation (for method 1)                 ║ 4     ║
║ DTO classs creation (for method 1)           ║ 0.5   ║
║ DAL/BL Method (for method 1)                 ║ 0.5   ║
║ NUnit Unit Testing (for method 1)            ║ 3     ║
║ Concurrency Handling (for method 1)          ║ 1     ║
║ HTML layout and styling                      ║ 6     ║
║ Tabular Data display in UI                   ║ 3     ║
║ Input Validation                             ║ 2     ║
║ Ajax Calendar Control                        ║ 1     ║
║ Hide/Show grid columns                       ║ 4     ║
║ Asynchronus data loading inside div          ║ 2     ║
║ Third Party file upload control              ║ 2     ║
║ Other Client side Manipulations with Jquery  ║ 2     ║
║ Export to Excel                              ║ 5     ║
║ Coding Standard Check                        ║ 1     ║
║ Exception Handling                           ║ 0.5   ║
║ Integration Data Verification                ║ 0.5   ║
║ Design document update (based on deviations) ║ 1     ║
╚══════════════════════════════════════════════╩═══════╝

Answer 1

Firstly, you should be clear on the terms you are using. An estimate, which should be a range of results, is different than a target, which is a single number to which you are marching and which lies somewhere in the range of your estimate. So you are talking about targets.

The rule is easy: you break down your work to the smallest level that you need to manage it, and by "manage it" I mean such that you can analyze where you are in your progress, what is causing your variances, and where you can make a credible prediction as to where you are likely going. That level is different for every project and for every PM. At the end of the day, you need to be comfortable with it.

The break down of work is not free. The more you break it down, the more it costs to track it and control it, the more complex it is and far easier to get "lost" in the details. So it becomes a balance between your ability to manage it and the costs to control it.

Many organizations apply rules, e.g., you must break down your work so the duration or work does not exceed x days or hours. I dislike those rules; it should be flexible. The one rule I do like, however, is that the work should be broken down so you have at least one, better two, tangible milestone or completion products/tasks within your reporting period, so that you can measure your work using EV, critical path management, etc. If you cannot reasonably break it down to have such a milestone within the period, so be it, but that should be an exception versus a rule and you need to be comfortable in flying blind for that reporting period.

Remember that everything is variable. We do not live in a deterministic world, but a probabilistic one. I prefer to estimate and target in days of duration versus hours. The variability in days is enough to cope with. In hours, the variability would be too crazy to analyze and would like not add any value. Your variance analysis would include things like 'Harry went to the bathroom at 2:00 pm and returned to work at 2:07 pm." :)

Answer 2

It looks detailed enough to me if it is in days. If it is in hours, then it is too detailed. A half an hour work rarely takes half an hour. Usually, it is more.

There is an "Exception Handling" task, which may not be a good idea to do separately. Additionally, in comparison to the other tasks the time you'll spend on it is technically zero.

Here is a scenario. You've finished all the other tasks, but it turns out that you have to rewrite several classes because of the complexity the "Exception Handling" brings in. It is better to do the error handling at that task it belongs to, and try not to underestimate it.

If you have to provide a schedule or a plan based on your estimates, try to add some buffers. It is really hard to set the right size of the buffer (it really depends on the environment, the team, the infrastructure), but a number between 50% and 30% usually does the trick.

Answer 3

Ideal Hours vs. Everything Else

Your work breakdown seems to be based on ideal hours. While there are proponents of this approach, ideal hours rarely track with any precision since estimates are usually a distribution. Another person said:

[P]recision doesn’t equal accuracy and accuracy is what we’re really after.

In other words, whether any given task will take 30 minutes of wall-clock time or not is an educated guess, and doesn't really tell you how much process overhead, task-switching time, or other issues will impact delivery of a given unit of ideal time. The real underlying question is how many ideal hours one can actually expect to complete in any given cycle, and your WBS doesn't really say anything about that.

Granularity vs. Clarity

Granularity should result in clarity on several key points:

1. Dependencies.
2. Requirements.
3. Success criteria.
4. Implied or explicit failure criteria.

Your WBS doesn't address any of those things. For example, what are the dependencies of "Export to Excel?" How will you know if it's done? How will you know if it was done right?

These things matter because your time estimates should be based on those things. Perhaps you and your team have some implicit understanding of what that task means, and how it fits in with everything else, but it is unlikely to be documented or transparent enough to make the estimate of "5 hours" anything but an opaque guess based on indeterminate criteria.

Note that this doesn't mean you have to decompose the task further. It may or may not already be granular enough. The real issue is that it isn't clear.

Have the Right People Estimate

Finally, in Scrum the cross-functional team provides the estimates because they are the ones doing the work. As a result, they are the only ones who know what skills and tools they have at their immediate disposal for the task, and whether or not they have sufficient confidence in the estimate to commit to completing the work within a given time-box.

Confidence in estimates grows over time. The right questions to ask are:

1. Whether the WBS you presented is sufficient to give you and your team confidence in the estimates.
2. The granularity of individual WBS elements is sufficient to track progress and deviations from the schedule.
3. The clarity of the WBS elements is sufficient to communicate effectively within the team, and between the team and the organization.

Definitely ask those questions. However, the only people who can answer them already work with you; the answers can't be found on the Internet.

Answer 4

More information is needed to determine if granularity is about right. I'll suggest some criteria that can be applied:

1. Are there any external dependencies internal to any of the tasks? If so, obviously, the task needs to be split to allow the dependency to be tracked.

2. Is there significant adverse risk associated with any of the tasks? If so, can the task be split to allow the risk to be evident or not, and can the earlier portion of the task, or both portions be scheduled earlier to allow for better risk management?

3. Drawing a bit from agile, is there a result that could be independently verified as complete (even though the evaluation might not take place)? For example, untested code is difficult to verify without testing. So, untested code is output, but it is not outcome. It is possible to write several thousand lines of code which have so many bugs that the code will need to be discarded and rewritten. Only tested code can be said to be complete. Output without outcome is valueless.

Answer 5

Based on my experience, breaking down tasks into more granularity can lead to additional complexity and time rather than simplification. The WBS for the web construction is appropriate since the design of the UI and classes is complete. It is important to proceed promptly and accurately.