Technische Universitt Mnchen

Fakultt fr Informatik
Lehrstuhl fr Angewandte Softwaretechnik
Prof. Bernd Brgge, Ph. D.

Handout

zum

Hauptseminar im Wintersemester 2007/08

Agile Techniques for Project Management and Software Engineering

Agile Estimating and Planning

Betreuerin: Jennifer Schiller

Bearbeiter: Victoria Bodishevskaya

Bachelor Wirtschaftsinformatik
im 5. Fachsemester

Eingereicht am: 29. November 2007

I Contents
1. The Problem and the Goal...................................................................................................... 1
1.1 The Purpose of Planning .................................................................................................. 1
1.2 What Makes Planning Agile ............................................................................................ 1
1.3 Why Planning Fails .......................................................................................................... 3
1.4 Traditional Estimating Approaches.................................................................................. 4
2. Estimating Size....................................................................................................................... 4
2.1 Estimating Size with Story Points .................................................................................... 5
2.2 Velocity ............................................................................................................................ 6
2.3 Estimating in Ideal Days .................................................................................................. 6
2.4 Choosing between Story Points and Ideal Days............................................................... 6
2.5 Techniques for Estimating ............................................................................................... 7
3. Planning for value .................................................................................................................. 9
3.1 Prioritizing Themes .......................................................................................................... 9
3.2 Prioritizing Desirability.................................................................................................. 11
4. Why Agile Planning Works ................................................................................................. 12
5. Bibliography......................................................................................................................... 12

II List of figures

Figure 1: Traditional and agile views of reducing uncertainty 1

Figure 2: Estimating the duration of a project begins with estimating its size 4
Figure 3: Additional estimation effort yields very little value beyond a certain point 7
Figure 4: Combining risk and value in prioritizing features 10
Figure 5: The Kano Model of Customer Satisfaction 11

II
1. The Problem and the Goal

1.1 The Purpose of Planning

To introduce the agile approach to estimating and planning it is first important to understand
the purpose of planning.
Planning is an attempt to find an optimal solution to the overall product development question
of which features with which resources and in what timeline should be developed. This
question, however, cannot be answered all at once. It must be answered iteratively and
incrementally.
A good planning process supports answering this question in many ways.
Firstly, planning provides insights into the risks, inherent in the project. The earlier the team
realises the possible risks, the easier it will be to eliminate and avoid them.
Secondly, throughout a project we learn much about the product, the technologies and about
the team itself. It is critical to include this new knowledge continuously into the planning
process. On the long run, it helps to reduce uncertainty and the risk of developing the wrong
product.
Thirdly, while planning a project, many trade-off decisions between functionality and effort,
development time and cost must be made. Schedules and cost estimates support better
decision making by showing the consequences of pursuing this or that alternative and by
conveying reliable information to the stakeholders.
A good planning process also provides reliable estimates, which in their turn enable reliable
delivery of the promised features. This helps to establish trust between the developers and the
customers of the product.

1.2 What Makes Planning Agile

A good plan is one that is sufficiently reliable, so that it can be used as the basis for making
decisions about the product and the project (Cohn, M. 2005, p. 10).
Throughout a project, two types of knowledge are generated: knowledge about the product
and knowledge about the project.
Product knowledge is the knowledge about what will be developed. It is the knowledge
about the features that will be included and about those that will not be included.
Project knowledge is the knowledge about how the product will be created. It includes
knowledge about the technologies that will be used, about the skills of the developers,
about how well the team functions together and so on.

Figure 1: Traditional and agile views

of reducing uncertainty.
Adapted from Laufer (2006). In:
Cohn, M. 2005, p. 83.

1
The flip side of acquiring knowledge is reducing uncertainty. At the start of the project there
is uncertainty about the features the new product should contain, the so called end
uncertainty. And there is also the uncertainty about how to build the product, the so called
means uncertainty (Laufer 2006 In: Cohn, M. 2005, p. 83). Product knowledge reduces the
end uncertainty. Means uncertainty is reduced through acquiring project knowledge.

Traditional approaches to planning, such as those following the waterfall process, try to
eliminate all uncertainty about what is being built before tackling the uncertainty of how it
will be built. Traditional teams assume that before they begin developing there will be no
remaining uncertainty about the end that is being pursued.

Agile teams have a contrast view on reducing uncertainty. They acknowledge that it is
impossible at the start of a project to eliminate all end uncertainty. Parts of the product should
be developed, shown to the customer, feedback needs to be collected, opinions refined and
plans adjusted. While this is occurring, the team will also be learning more about how they
will develop the system. This leads to simultaneously reducing both end and means
uncertainty.
Since agile teams acknowledge, it is not possible to define a project totally at its outset, they
are willing to revise the plan through the course of the project and update it regularly.
Changing the plan means that the team has avoided mistakes and learned new things about the
product that is being developed, and about the tools and techniques being used. For this
reason, agile planning is spread more or less evenly across the whole duration of the project.

To put it in a nutshell, agile planning is

More focused on the planning rather than on the creation of a plan;
Encourages change;
Results in plans that are easily changed and
Is spread throughout the whole project.

Agile approach to planning implies multiple planning levels: the release, the iteration and the
daily plan. These three types of plans have different levels of precision.
Release planning is an iterative process of creating a high-level plan that covers a period of
three to six months. Release plan identifies the user stories to be included into a release and
the owners conditions of satisfaction, considering the goals for the schedule, scope and
resources. It is common for a release plan to be updated at the beginning of each iteration.
Iteration planning looks ahead the length of one iteration only, usually a period of two to four
weeks. Iteration planning is conducted at the start of each iteration and deals with splitting
user stories into smaller tasks that will be needed to transform a feature request into working
and tested software. Each task is then estimated and finally, the team must commit to the tasks
they have included into the iteration.
The final level of planning is daily planning. During their daily stand-up meetings, agile
teams allocate single tasks to specific individuals and revise their plans one more time.

2
1.3 Why Planning Fails
Traditional planning processes do not always lead to very satisfactory answers about the
combined scope/schedule/resources question for a new product:
Nearly two thirds of projects significantly overrun their cost estimates
Sixtyfour percent of the features included in products are rarely or never used
The average project exceeds its schedule by 100% (Cohn, M. 2005, p. 11)

The basic planning tools, used on traditional projects to illustrate the schedule, are activity
charts, also called Gantt charts. Those show the dependencies between the activities, their
estimated duration and the specialists, assigned to the single tasks. Gantt charts are the output
of the planning process and usually must be available before the implementation begins.
(Sommerville, I. 2004, p. 101)

The first reason, why traditional planning approaches fail, is the focus on completion of
activities rather than delivering of features.
Activities are usually not independent. One thing going wrong is enough to cause delays, so
that lateness is finally passed down the whole schedule.
Activities also distract attention from the features, which are the true units of customer value.
(Cohn, M. 2005, p.12) To monitor the state of the software being developed, traditional teams
establish a series of milestones, as end-points of activities. The output of a milestone is
usually a short report. Reports are presented then to the management in order to check the
progress, but they are normally not delivered to the customer. (Sommerville, I. 2004, p. 98)
This shows that customers get no value from completion of an activity. (Cohn, M. 2005, p.13)
Agile teams value working software over comprehensive documentation; hence they deliver
coded, tested and potentially shippable software of releasable quality each iteration.

A second reason why traditional approaches often fail is multitasking.

On traditional project, the tasks are usually assigned well in advance (consider the Gantt
charts). Since, it is not possible to allocate work efficiently in advance, projects often become
some activities finish late. To avoid delivering late, many teams see multitasking as a possible
cure. But simultaneously working on more than two tasks reduces productivity rapidly and
exacerbates the problem dramatically.

Thirdly, on traditional projects work is not prioritized by its value to the users and customers.
When the project schedule runs out of time, features are inevitably dropped. Because the
features are developed in the order deemed most efficient by the developers, the dropped
features are not necessarily those with the lowest value to the users.

A fourth shortcoming with traditional approaches to planning is the failure to acknowledge

uncertainty. The assumption that the initial requirements analysis led to a complete and
perfect specification of the product can result in completing a project on schedule, but without
including important capabilities that were identified after the plan was created.

And finally, many traditional teams equate estimating with committing. An estimate is a
probability, and a commitment cannot be made to a probability (Cohn, M. 2005, p. 13).
Commitments are made to dates.

3
1.4 Traditional Estimating Approaches
There are two types of productivity estimates, used on traditional software development
projects to define the project cost and schedule; these are size- and function- related metrics.
Size-related metrics help to estimate the size of some activity. The most commonly used ones
are the lines of delivered source code per programmer-month (LOC/pm), the number of
delivered object code instructions or the number of pages of system documentation. The
LOC/pm, for example, can be computed by dividing the total number of LOC by the total
time in programmer-months required to complete the project. (Sommerville, I. 2004, p. 615f)
Function-related metrics relate to the overall functionality of the delivered software. The best-
known metrics of this type are function points and object (or application) points
(Sommerville, I. 2004, p. 615f)
Estimating size with lines of source code per programmer-month (LOC/pm) has, however a
number of disadvantages:
Lines of code are often difficult to count, because some instructions may expand to
several lines of code and there can be more than one statement per line.
Comparing productivity across programming languages is often misleading. The number
of LOC for implementing the same functionality may vary, depending on the
programming language used.
Estimating in function points per person-month is independent of the implementation
language, and measures the functionality of the code. The estimates delivered through the
function-point count depend, however, on the estimators judgement, because each estimator
has its own notion of complexity. (Sommerville, I. 2004, p. 618)

The problem with the measures that rely on the amount produced in a given time period is
that they take no account of quality characteristics such as reliability and maintainability.
They imply that more always mean better (Sommerville, I. 2004, p. 619). However, if you
are continuously working at code simplification and improvement, then counting lines of code
does not mean much (Beck, 2000 In Sommerville, 619).

2. Estimating Size

Agile teams separate estimates of size from estimates of duration. To create a schedule, agile
teams first estimate the size of the system they are going to develop and then derive the
duration of the project.
The two common techniques for estimating size on agile projects are estimating in story
points and estimating in ideal days.

Figure 2: Estimating the duration of a project begins with estimating its size.
Source: Cohn, M. 2005, p. 34.

4
2.1 Estimating Size with Story Points
On the contrary to traditional approaches, agile teams focus on delivering user-valued
features, rather than on completing isolated tasks. For this reason agile teams work with user
stories. A user story is a brief description of functionality as viewed by a user or a customer of
the system. User stories are free-form, but it is useful to think of user stories generally fitting
the form: As a <type of user>, I want <capability>, so that <business value>. For example
As a book buyer, I want to search for a book by ISBN, so that I can find the right book
quickly.

Story points are a unit of measure for expressing the overall size of a user story, feature or
other peace of work.( Cohn, M. 2005, p. 36) When estimating with story points, agile teams
assign a point value to each item. Story points represent the amount of effort, involved in
developing a feature, its complexity and the amount of risk inherent in it.

The raw values we assign are unimportant. What matters are the relative values. A story that
is assigned a two should be twice as much as a story that is assigned a one. It should also be
two-thirds of a story that is estimated as three story points.( Cohn, M. 2005, p. 36)

There are two common ways of getting started with estimating in story points. You can either
select one of the smallest user stories and estimate it at one story point; or you can choose a
medium one, and assign it with the number of story points, that is somewhere in the middle of
the range you are going to use. Once youve estimated the first user story, the estimation for
each additional story should be derived by comparing it with the first one or with any others
that have already been estimated. (Cohn, M. 2005, p. 36)

Example
To show how estimating with story points works, imagine you are going to paint an
unfamiliar house, that you have never seen before. Before starting painting the house, you
want to estimate how long this job is going to take you. But the only thing you can use for
your estimation is the floor plan, which doesnt contain the dimensions. Suppose, you
estimate the effort it is going to take you to paint each of the smaller bedrooms at five points.
The five does not mean anything, however it indicates, that the amount of effort is going to be
just the same for each of these rooms. The master bedroom seems to be twice as big as the
smaller ones. For this reason you can assign ten points to it.
Although you cannot infer the dimensions from the floor plan, your estimates still remain
useful, because these are the relative estimates of the effort of painting each room. If you find
out, that the smaller bedrooms are twice the size you thought, all the other rooms are also
twice the size you thought. Except for the rate of progress, which will be slower, all the
estimates remain the same.

This example shows that estimating with story points completely separates the estimation of
effort from the estimation of duration. Separating these two aspects, allows each of them to be
estimated independently. That means you are no more estimating the duration of the project,
but you are deriving it.

5
2.2 Velocity
A key tenet of agile estimating and planning is that agile teams estimate size, but derive
duration. For this reason it is important to introduce the concept of velocity.
Velocity is the measure of the teams rate of progress per iteration. You can calculate the
velocity by summing the number of story points assigned to each user story that the team
completes during the iteration.
If a team completes two five-point user stories during the iteration, their velocity is ten. If
they are able to complete three user stories, each estimated at five story points, their velocity
is fifteen (Cohn, M. 2005, p. 39).

If we sum the story point estimates for all desired features we come up with a total size
estimate for the project. The duration of a project can be derived by taking the total number of
story points and dividing it by the velocity of the team.

2.3 Estimating in Ideal Days

Agile teams may also choose to estimate user stories or other work in ideal days. Ideal time is
the amount of time something takes when stripped of all peripheral activities. Elapsed time,
on the other hand, is the amount of time that passes on a clock (or a calendar). To illustrate
this, consider that the ideal time of a game of American football is 60 minutes, but its elapsed
time is about three hours, because it includes numerous breaks and timeouts for commercials.
On a software project, ideal time differs from elapsed time because of the natural overhead
that developers experience every day, like meetings, phone calls, Email etc.
The amount of time a user story will take to develop can be more easily estimated in ideal
time than in elapsed time. When estimating in ideal days you assume:
The story being estimated is the only thing you will work on.
Everything you need will be on hand when you start.
There will be no interruptions.

While estimating in ideal days, one aggregate estimate should be assigned to each user story.
Instead of estimating that a user story will take two ideal days from a programmer, one ideal
day from a database engineer and two ideal days from a tester, it is better to sum these up and
say that the story as a whole will take five ideal days.

2.4 Choosing between Story Points and Ideal Days

A team may choose to estimate in either story points or ideal days. Each is a viable choice
with advantages to recommend it:

Story points have the advantage of helping promote cross-functional team behaviour.
Additionally, they do not need to be re-estimated if the team improves in the
technology or the domain, because story points are a more pure measure of size. In
this case you only need to re-calculate the velocity.
Estimating in story points is often faster than estimating in ideal days.
Finally, unlike ideal days story points can be compared among team members. If one
team member thinks something will take her four ideal days and another team member

6
 thinks it will take him one ideal day, they may each be right, yet they have no basis on
which to argue and establish a single estimate.

Ideal days are less strict, than story points and have the advantage of being more easily
explained to those outside the team and of being easier to start with.

Mike Cohn, the author of the book, prefers estimating with story points, because the benefits
they offer as a pure measure of size are more compelling.

2.5 Techniques for Estimating

Expending more time and effort to arrive at an estimate does not necessarily increase the
accuracy of the estimate. The relationship between estimate accuracy and effort is shown in
Figure 3.

Figure 3: Additional estimation effort yields very little value beyond a certain point.
Source: Cohn, M. 2005, p. 50.

No matter, how much effort is invested, the estimate is never at the top of the accuracy
axis.
Secondly, little effort is enough to move the accuracy up dramatically from the
baseline

The amount of effort put into an estimate should be determined by the purpose of that
estimate. Agile teams embrace the idea that small efforts are rewarded with big gains and
choose to be closer to the left in a figure like Figure 3.

Although it is well-known that the best estimates are made by those who will do the work , on
an agile team you dont know in advance who will do the work. That is why estimates are
derived collaboratively by the team, which includes those who will do the work.

Studies have shown that people are best at estimating things within one order of magnitude.
For this reason one should use a predefined scale while estimating. Features that will be
worked on in the near future and that need fairly reliable estimates should be made small
enough that they can be estimated on a nonlinear scale from 1 to 10 such as
1, 2, 3 5, and 8 (Fibonacci sequence) or
1, 2, 4 and 8 (each number is twice a number that precedes)
Larger features that will most likely not be implemented in the next few iterations can be left
larger and estimated in units such as

7
 13, 20, 40, and 100
If you decide to choose to include 0 (for tiny features) in your estimation scale, you should
understand that 13x00.

Although we generally want to estimate user stories whose sizes are within one order of
magnitude, this cannot always be the case. For features hat were not sure we want or for
features that may not happen in the near future, it is often desirable to write one much larger
user story. Large user stories are called epics.
Additionally, a set of related user stories may be combined and treated as a single entity. Such
a set of user stories is referred to as a theme.
While aggregating some user stories into themes and epics, it is important to realise that their
estimates will be more uncertain as those of small user stories.

The three most common techniques to derive an estimate are expert opinion, analogy and
disaggregation.

In an expert opinion-based approach, an expert is asked to give an estimate. This technique is

very accurate, but is much more useful on traditional projects. On an agile project, estimates
are assigned to user-valued functionalities. Developing these requires a variety of skills,
normally performed by more than one person. This makes difficult to find suitable experts.

When estimating by analogy, the estimator compares the story being estimated with one or
more other stories.

Disaggregation refers to splitting a story or feature into smaller, easier-to-estimate pieces.

However you should be careful not to go too far with breaking a feature into multiple smaller
items, because of
The likelihood of forgetting a task, and
The problems arising while summing estimates of lots of small tasks.

The most reliable estimating technique for an agile team is to estimate by playing planning
poker. Planning poker combines expert opinion, analogy, and disaggregation.
The goal of the planning poker is not to derive a perfect estimate. Rather, the goal is to arrive
at a reliable estimate without wasting much time on the estimating efforts.

Participants in planning poker include all of the developers on the team. If these exceed ten
people, the participants will be split into two teams. The product owner participates in
planning poker, but does not estimate. (Cohn, M. 2005, p.35-60)

Planning poker
1. At the start, each estimator is given a deck of cards. Each card has one of the valid
estimates written on it. For example, a deck of cards that reads
0, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
2. The moderator (the product owner or an analyst) reads the description for each user story
or theme to be estimated. Then it is discussed briefly.
3. As next, each estimator privately selects a card that represents his or her estimate.
4. As soon as all have made a selection, all the cards are simultaneously turned over.

8
5. If estimates differ, the high and low estimators explain their estimates. The group can
discuss the story and the estimates for a few more minutes. The moderator can take any
notes she thinks will be helping when this story is being programmed and tested. After the
discussion, each estimator re-estimates by selecting a card. The goal for the estimators to
converge on a single estimate that can be used for the story. It rarely takes more than three
rounds, until an agreement on an estimate is reached.

There are several reasons why planning poker works so well:

First, it brings together multiple expert opinions. Because these experts form a cross-
functional team from all disciplines on a software project, they are better suited to the
estimation task as anyone else.
Second, a lively dialogue ensues during planning poker and estimators are called upon by
their peers to justify their estimates. This improves the accuracy of the estimates,
especially on the items with large amounts of uncertainty.
Third, studies have shown that averaging individual estimates leads to better results as do
group discussions of estimates.
Finally, planning poker works because its fun. (Cohn, M. 2005, p. 56-59)

3. Planning for value

3.1 Prioritizing Themes
Because there is rarely, if ever, enough time to do everything, we need to prioritize what is
worked on first. The responsibility is shared on agile projects among the whole team. Since, it
is difficult to estimate the value of such small units of functionality as a single user story,
these are aggregated into themes. Themes are then prioritized relative to one another for the
purpose of creating a release plan. Themes are selected such, that each defines a discrete set
of user- or customer-valued functionality.

There are four primary factors which should be considered while prioritizing:
The financial value of having the features.
The cost of developing (and perhaps supporting) the new features.
The amount and significance of learning and new knowledge created by developing
the features.
The amount if risk removed by developing the features.

These four factors are combined by thinking first of the value and the cost of the theme.
Doing so sorts the themes into an initial order. Themes can then be moved forward or back in
this order based on the other factors (Cohn, M. 2005, p. 79-88).

Financial Value
The first factor in prioritizing the work is the financial value of the theme (the business
value). What is meant is the amount of money the organization will earn or save by having the
new features included in the theme. It is usually sufficient to forecast the revenue and
operational efficiencies for the next two years.
A good way of modelling the return from a theme is to consider the revenue it will generate
from
New customers (new revenue),

9
 Current customers buying more copies or additional services (incremental revenue),
Customers, who might have gone to a competitive product (retained revenue), and
Any operational efficiencies it will provide (e.g. some new tools assisting the work of
developing software).

After estimating the cash flow stream that will be generated by each theme, the team should
think of the ways of analyzing and evaluating those cash flow streams. The four good ways to
do that are net present value, return on investment, payback period, and discounted payback
period. By calculating these values for each theme, the product owner and team can make
intelligent decisions about the relative priorities of the theme (Cohn, M. 2005, p.91-95).

Cost
Another huge determinant in the overall priority of a feature is its cost. An important aspect
about the cost is that the cost can change over time. Some features cost less, when
implemented later. This happens, because the change requests can be avoided or faster and
simpler implementations can be discovered. That is why the best way to reduce the costs of
change is to implement the feature as late as possible.

Risk
Closely aligned with the concept of new knowledge is risk- the final factor in prioritization.
The following types of risk exist, while developing software:
Schedule risk (the risk of delivering late)
Cost risk (the risk of exceeding the costs)
Functionality risk (the risk of failing to deliver a properly functioning product)

Figure 4: Combining risk and value in prioritizing features.

Source: Cohn, M. 2005, p. 85.

The classic struggle exists between high-risk and high-value features of a project. The team
must always choose if they start by focusing on high-risk features that could jeopardize the
entire project; or high-value features, that will deliver the most customer satisfaction.

To prioritize work optimally, it is important to consider both risk and value. The high- value,
highrisk features should be developed first. These features develop the most value, and
working on them eliminates significant risks. Next are the high-value low-risk features. These
features offer as much value as the first set, but they are less risky. Therefore, they can be
done later in the schedule. Low-value, low-risk features are sequenced third because they will
have less impact on the total value of the product if they are dropped, and because they are

10
low-risk. Finally, features that deliver low value, but are high risk, are best avoided. There is
no reason to take on a high degree of risk for a feature of limited value.

The developing team should be aware, that a features risk and value profile changes over the
time. A low-value, low-risk feature today in the Avoid quadrant of the Figure 4 could be in
the Do first quadrant some months from now, if all other features have been finished (Cohn,
M. 2005, p.84f).

3.2 Prioritizing Desirability

There exist two approaches to prioritizing desirability of a feature: Kano analysis and relative
weighting.

Kano Analysis
According to the prioritizing process, originated from Noriaki Kano, all the features can be
separated into three categories:
Threshold, or must-have features
Linear features
Exciters and delighters
Threshold features must be included into the product, in order it to be a success. However,
improving the amount or the performance of a feature has little impact on customer
satisfaction.
Linear features are called so, because customer satisfaction is linearly correlated with the
quantity of those ones. The better such features perform, the more satisfied the customer will
be. For this reason, also the product price is often related linearly to the linear attributes.
And finally exciters and delighters are those features, providing the greatest customer
satisfaction and adding a price premium to the product. However, the lack of these features
will not decrease the customer satisfaction below neutral. Therefore, exciters and delighters
are also often called unknown needs, because customers dont know they need this features
until they see them.
In order to segregate the features into these three categories, the potential users are asked two
questions: how they would feel if the feature were present, and how they would feel if it were
not present (Cohn, M. 2005, p. 112f).

Figure 5: The Kano Model of Customer Satisfaction.

Source: Cohn, M. 2005, p. 113

11
While prioritizing, one should focus on developing all the must-have features, because they
are required for a product to play in its market segment. Since these features are mandatory,
they should be available before the product is released.
Secondly, you should emphasize implementing as many linear features as possible, because
they lead directly to the customer satisfaction.
Finally, at least some delighters should be included into a release.

While prioritizing, it is important to keep in mind that once delighters, some features get over
to must-haves over time (Cohn, M. 2005, p. 113f).

Relative Weighting
Relative weighting is a prioritizing approach, which is similar to Kano analysis, because it
also considers the positive impacts of the presence of a feature and the negative impacts of its
absence.
On the contrary to Kano analysis, this approach relies on expert judgement. The features are
prioritized collaboratively by the team and the product owner, who takes part in sorting the
features out for the next release.
According to the method of relative weighting, all the features are assessed in terms of the
benefits they will bring, when implemented; and the penalties incurred, when they are not
implemented. (Cohn, M. 2005, p. 117f).

4. Why Agile Planning Works

The following are the guidelines considering the main reasons why agile estimating and
planning works:
Replanning occurs frequently
Estimates of size and duration are separated
Plans are made at different levels
Plans are based on features, not tasks
Small user stories keep work flowing
Work in process is eliminated every iteration
Tracking is at the team level
Uncertainty is acknowledged and planned for (Cohn, M. 2005, p. 249-254).

5. Bibliography

Cohn, M. (2005): Agile Estimating and Planning. 1st Edition, Prentice Hall, Stoughton 2005.

Sommerville, I. (2004): Software engineering, 7th Edition, Pearson Addison-Wesley, Boston

2004.

12