CSC/ECE 517 Fall 2010/ch6 6c AW

Estimation in Agile Projects

Introduction

Agile software development comprises a group of various methodologies that guide the development of software projects in an iterative and evolutionary way. Collaboration among teams, individuals, and the customer are emphasized in these processes, as it pushes the goal of producing good, functioning, relevant deliverables. Examining the beginning stages of the development life cycle in agile projects, this chapter on estimation will cover the motivation behind estimation, the common bases for estimation, the common techniques used in estimation, and how agile project estimation differs from traditional project estimation methods.

Purpose of Estimation

Estimation is an essential element of any and every software development process. It cannot 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. These exemplify an approach to software development that is closely controlled and connected among team members and the customer.

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]. The velocity can be roughly translated as much work an individual or team can take on per iteration, providing an excellent guideline for estimating how to break down the whole project into manageable parts.

Estimation Techniques

The ways of engaging in an estimating session are about as numerous as the methods of developing the software itself. For an agile methodology, it is important to always concentrate on those basic desires of speed and flexibility, as well as heavy interaction among teammates and with the customer. The following techniques highlight what are considered best practices by experts in agile software development, but are by no means a comprehensive list of procedures.

Planning Poker

Derived from the Wideband Delphi estimation method, planning poker is a "consensus-based technique for estimating, mostly used to estimate effort or relative size of tasks in software development" [6]. Pulling from the Wideband Delphi ideas of generating a consensus from all participants involved, planning poker throws the steps of estimating size, time, and effort to accomplish sections of a system into the framework of a game: poker! The way to play is simple: after discussing each user story, every player selects a numbered card from their deck that represents the agreed-upon unit of measurement (for example, number of story points). All individual estimates are kept secret until everyone has chosen, then all estimates are revealed and examined for consistency.

Image from PlanningPoker.com [7]

If estimates are the same group-wide, the hand is over and the team has decided upon a value for that user story. If the estimates vary widely, then more discussion is necessary, followed by another round of planning poker conducted in the same fashion as described above [8]. This extremely popular method can be employed online, with a pack of specialized cards, or in other make-shift fashions; it is a quick and simple technique to efficiently reach a consensus that will accurately estimate software development tasks.

Burn-down Charts

Just as estimation can be examined in regard to size or velocity, there are varying techniques that emphasize examining size for estimation (as in planning poker) as well as that emphasize looking at velocity for estimation. One of those kinds of techniques is a graphical approach using burn-down charts. Burn-down charts express the amount of work (described as number of story points or ideal days) left in a single iteration. This allows for an easy illustration of what is left to do per time period, which contributes to the estimation of a project's velocity.

Image from User Stories Applied ^[1]

The slope of the line as shown above reflects the positive velocity of the team: the smaller slope during the first iteration illustrating a velocity of 20 story points/iteration, whereas the greater slope during the second iteration illustrates a velocity of 40 story points/iteration. Thus during estimation, the group of developers can pictorially see how 'fast' things need to be completed, and can arrange the whole schedule accordingly.

Re-estimation

As stated time and time again, agile software development methods encourage lightweight and flexible approaches that leave a team open to changed requirements, unforeseen circumstances, and similar problems. To that end, re-estimation is a vital aspect in the development life-cycle because it allows for a structured change based on the same kinds of data which were examined for the original estimation stage.

Triangulation is a term used to describe the process of re-estimating once initial estimates have been completed for each user story (or equivalent unit). Specifically, it is a technique that examines the estimate of one user story against other values for different user stories. For example, if one user story is decided to take 2 days to complete, and another user story is decided to take 4, then everyone should concur that the second will take twice as long as the first. This way, the meaning of the agreed-upon unit (NUT) does not vary from one user story's estimate to another ^[1].

Comparison

Traditional software development relied on a very strict sequential basis. As such, each phase of a project must be completed before the next, the one aspect building upon another. As expressed in the typical waterfall model, first came requirements gathering, then design, integration, testing, installation, and maintenance [9]. Some essential problems with this approach were the assumptions it relied upon: all requirements are known at the beginning of the project and furthermore are static, little communication is needed with the customer because all information is contained in said requirements, and there is only one (or, very few) release time. From these concerns, the intrinsic differences between agile project estimation and traditional project estimation are apparent.

Formal estimation models such as SLIM or COCOMO mimic the traditional software development approach through strict, complex estimation algorithms applied to the project in the requirements gathering phase. Agile software development estimation methods, however, as seen above, center around scenario-dependent aspects like user stories from which developers employ best-guess estimates to formulate a project-wide estimate. Contrary to many people's intuition, the latter most often proves a more accurate method of estimation than the former [10]. Given the frequently long processes involved in the completion of an entire software project, agile estimation techniques offer a lot of advantages over the traditional methods, not the least of which is learning from past mistakes.

Summary

As illustrated above, estimation is a key component in any kind of software development, whether large or small, or during a short or long time frame. The agile software development process relies on swift adaptation to requirements and input from the customer, and consequently leans on estimation techniques that reflect the goals of swift decisions, tolerance for imprecision, specification flexibility, and usefulness in determining quick periodic release dates.

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.

[5] Guideline: Agile Estimation, Retrieved November 16th, 2010, from EclipseWiki: http://epf.eclipse.org/wikis/openup/core.mgmt.common.extend_supp/guidances/guidelines/agile_estimation_A4EF42B3.html

[6] Planning Poker, Retrieved November 14th, 2010, from Wikipedia: http://en.wikipedia.org/wiki/Planning_poker

[7] Planning Poker, Retrieved November 14th, 2010, from http://www.planningpoker.com

[8] Cohn, M. Agile Estimation and Planning, Addison Wesley Longman, 2005.

[9] Agile Methodology, Retrieved November 13th, 2010, from http://agilemethodology.org/

[10] Estimating on Agile Projects, Retrieved November 16th, 2010, from http://www.drdobbs.com/architecture-and-design/223100694