CSC/ECE 517 Fall 2010/ch6 6c AW

Estimation in Agile Projects

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 [2]. A user story is essentially the same as a use case, but is worded in a more business-friendly manner [3]. For example,

Starting Application
When the user starts the application, it begins by bringing up the login page.

This type of specification, in contrast to the more software-oriented terminology, 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 [4].

Each individual programmer can be assigned tasks to do based on these story points that measure the user stories, breaking down the larger project into manageable units that can be completed individually. Story estimates as a whole, however, are completed and owned by the team in charge of developing the system. Story estimates simply refer to the collection of smaller tasks that together make up a more comprehensive user story [1].

Based on Velocity

Velocity is a familiar physical concept: it is the speed and direction of an entity. In the agile software development sense, velocity refers to the rate of progress for a project. This can be measured in a few different ways, depending on what size estimations (as discussed above) are used, but the most common way is simply to define velocity as the number of story points completed (not in progress) per iteration [5].

References

[1] Cohn, M. User Stories Applied: For Agile Software Development, Addison-Wesley Professional, 2004.

[2] 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

[3] User Story and Use Case Comparison, Retrieved November 13th, 2010, from http://www.c2.com/cgi/wiki?UserStoryAndUseCaseComparison

[4] Joshua Kerievsky on extremeprogramming@yahoogroups.com, August 5, 2003.