Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

use case based Project estimation ?

 
kri shan
Ranch Hand
Posts: 1460
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How can i calculate number of days based on use case for Project estimation ?
 
Allan Christensen
Greenhorn
Posts: 24
  • Mark post as helpful
  • send pies
  • 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
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • 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.
 
Scott Ambler
author
Ranch Hand
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have some advice posted at Agile Project Planning tips.

- Scott
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • 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!
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic