CSC/ECE 517 Fall 2010/ch6 6c AW: Difference between revisions
Line 35: | Line 35: | ||
==References== | ==References== | ||
[[#References|[1]]] Cohn, M. ''User Stories Applied: For Agile Software Development'', Addison-Wesley Professional, 2004. | [[#References|[1]]] Cohn, M. ''User Stories Applied: For Agile Software Development'', Addison-Wesley Professional, 2004. | ||
[[#References|[2]]] User Story and Use Case Comparison, Retrieved November 13th, 2010, from http://www.c2.com/cgi/wiki?UserStoryAndUseCaseComparison | [[#References|[2]]] User Story and Use Case Comparison, Retrieved November 13th, 2010, from http://www.c2.com/cgi/wiki?UserStoryAndUseCaseComparison | ||
[[#References|[3]]] | |||
[[#References|[3]]] CSC/ECE 517 Fall 2010/ch4 4a RJ, Retrieved October 15th, 2010, from Textbook Wikipedia page: http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4a_RJ |
Revision as of 19:49, 17 November 2010
Estimation in Agile Projects
Introduction
Purpose of Estimation
Estimation is an essential element of any and every software development process. It can not only be utilized with respect to internal development and determining how to proceed on the programming side, but also with respect to interacting in a professional and honest manner with a customer. To that end, any estimation must also provide the ability to plan releases: thus, not only predict progress but also generate an accurate timeframe for deliverables.
The agile development methodology with respect to estimation centers around a few key concepts: a brief process, one that allows for adaptation and ambiguity, and yet one that provides useful information and progress reports [1]. Breaking the areas of estimation down further, three direct applications (purposes) can be identified: daily plans, iteration plans, and release plans. (three inner circles, find source!)
Types of Estimation
The primary step in estimating agile projects relies on the idea of a user story. As seen previously in Chapter 4a, Use Cases, a use case is a description of a sequence of possible actions undergone when a user interacts with the system. A user story is essentially the same as a use case, but is worded in a more business-friendly manner [2]. This is fully in accordance with the emphasis that agile development places on close cooperation with the customer during all stages of development.
Based on Size
With the user stories approach, the idea is to create small portions of what the system can do in relation to the user, and use these portions to estimate the size of a project (or iteration, release, etc). Story points are defined as the essential unit of measurement for a user story. Because of the desire to keep things flexible, the exact definition of a story point unit will vary from team to team and from project to project. Common ways to define them are as an ideal day or week of work or as one degree of complexity of a user story. Due to these varied meanings, it has been suggested that story points are measured in NUTs, or Nebulous Units of Time [3].
Based on Velocity
Estimation Techniques
Planning Poker
Burn-down Charts
Re-estimation
Comparison
General
Formal models
Summary
References
[1] Cohn, M. User Stories Applied: For Agile Software Development, Addison-Wesley Professional, 2004.
[2] User Story and Use Case Comparison, Retrieved November 13th, 2010, from http://www.c2.com/cgi/wiki?UserStoryAndUseCaseComparison
[3] CSC/ECE 517 Fall 2010/ch4 4a RJ, Retrieved October 15th, 2010, from Textbook Wikipedia page: http://pg-server.csc.ncsu.edu/mediawiki/index.php/CSC/ECE_517_Fall_2010/ch4_4a_RJ