• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

use case based Project estimation ?

 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
How can i calculate number of days based on use case for Project estimation ?
 
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It would depend on your project team. Try to compare it with similar work done previously.

You could also use formal techniques such as COCOMO2.

Kind regards,
Allan
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Basically gut feel, educated by prior experience. Best thing often is to have (at least part of) the team that will implement it contribute to the estimate.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I have some advice posted at Agile Project Planning tips.

- Scott
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's useful to estimate use cases or any sized tasks relative to each other. You don't need any idea how long they'll really take to do this, but you need to feel fairly sure that a 4 is twice as big as a 2, or these five tasks are all the same.

Then you can take a guess at how long some of them will take. You might decide an "4" takes one person a week.

You'll probably be asked to estimate the scope and staff and time for the entire project at this point. Such estimates are always rough unless you have solid experience with the architecture, the team, the customer, the domain and every other variable in the world. Which isn't often, is it.

Then pick some tasks to work on. I like Scott's link a lot where he shows planning the near range tasks in detail, and just blocking out big bunches of them in the future.

As you run a few tasks, validate that "4 equals a week" idea. If it turns out you can do 6 in a week, you're in great shape! If it turns out you can only do 2 in a week, you just learned this in a matter of days and you can adjust the plan accordingly.

BTW: I like one definition of risk as "uncertainty in the plan". If you don't know your variables or even one or two use cases well enough to estimate, that's a risk! Make sure everyone is aware of the uncertainty and has some idea what THEY will do if things are not as predicted. Otherwise we know exactly what YOU will do: 80 hour weeks!
 
reply
    Bookmark Topic Watch Topic
  • New Topic