Introducing Story Points and User

Stories to Performe Estimations in a

Software Development Organisation.
A case study at Swedbank IT.

Anna Georgsson

11th January, 2011

Master’s Thesis, 15 credits
Tutor at Swedbank IT: Mattias Nygren
Tutor at Umeå University: Anders Broberg
Examiner: Frank Drewes

UMEÅ UNIVERSITY
DEPARTMENT OF COMPUTING SCIENCE
901 87 UMEÅ
Abstract
Today, software can be found almost everywhere. The software development industry is a large
industry, but unfortunately the process of developing software is associated with exceeded budgets
and delays. Many companies now use one of the agile processes to meet the changing requirements
that often cause the problems. One of these companies is Swedbank IT, a company that has used the
agile process Scrum for some time but now wants to see how they can make further progress in their
agile work. The aim of the work presented in this thesis is to investigate if the introduction of story
points for estimation and further developing the utilisation of user stories when gathering
requirements can be used to achieve this progress.

The first part of this thesis is a literature study where the agile process Scrum is described. The
concepts user stories and story points are also explained. The second part is an interview study with
seven people working at Swedbank, all involved in software development projects. Finally the
interviews are analysed and some conclusions are drawn.

The conclusion is that the introduction of story points and further encouragement of the usage of user
stories can actually help Swedbank IT make further progress in their agile work. It can also increase
the efficiency of the team and facilitate the collaboration between Swedbank IT and the business side
at Swedbank.
Acknowledgements
I would like to thank a number of people who have helped me during this work:

The seven interviewees at Swedbank that so generously gave me their time, shared their
opinions/ideas and answered my questions. Without your help this work would have been impossible.

My tutor at Swedbank IT, Mattias Nygren for taking care of me during my time at Swedbank IT, for
sharing ideas on agile work and for always having such a positive attitude.

My tutor at Umeå University, Anders Broberg for intressant discussions on Scrum and feedback on
how to present the material in this thesis.

Last, but not least, many thanks to my beloved family who has encouraged and supported me all the
way to the finishing line.
Table of Contents
1 Introduction ..................................................................................................................................... 1
2 Method ............................................................................................................................................ 3
3 Agile Software Development .......................................................................................................... 5
3.1 Roles in Scrum ........................................................................................................................ 6
3.2 The Scrum Process .................................................................................................................. 6
3.3 Summary ............................................................................................................................... 10
4 Requirements ................................................................................................................................ 11
4.1 Use Cases .............................................................................................................................. 11
4.2 User Stories ........................................................................................................................... 12
4.3 Summary ............................................................................................................................... 13
5 Estimation ..................................................................................................................................... 15
5.1 Velocity ................................................................................................................................. 15
5.2 Measures of Size ................................................................................................................... 17
5.2.1 Agile Measures of Size ................................................................................................. 17
5.3 Planning Poker ...................................................................................................................... 19
5.4 Summary ............................................................................................................................... 20
6 Results of the Interview Study ...................................................................................................... 21
6.1 Agile Software Development ................................................................................................ 21
6.2 Requirements and User Stories ............................................................................................. 22
6.2.1 Advantages with User Stories ....................................................................................... 22
6.2.2 Problems with User Stories ........................................................................................... 23
6.2.3 Improvements ............................................................................................................... 23
6.2.4 Summary of Requirements and User Stories ................................................................ 25
6.3 Estimation ............................................................................................................................. 26
6.3.1 Advantages with Agile Estimation ............................................................................... 26
6.3.2 Problems with Agile Estimation ................................................................................... 27
6.3.3 Improvements ............................................................................................................... 27
6.3.4 Summary of Agile Estimation....................................................................................... 28
6.4 Summary ............................................................................................................................... 29
7 Conclusion .................................................................................................................................... 31
8 Discussion ..................................................................................................................................... 33
9 Bibliography ................................................................................................................................. 35
Appendix 1: Interview Guide in Swedish ............................................................................................. 39
Appendix 2: Quotations in Swedish...................................................................................................... 41
1 Introduction
Computers and hence software are ubiquitous today. According to a 2007 survey (Pew Research
Center, 2007), 82% of Swedes and 80% of Americans use computers. This implies that the software
development business nowadays is a large industry. In Sweden alone, SEK 60 billions are spent every
year on software development (Zirn, 2010). However, software development projects have often been
related to delays and exceeded budgets. In his book The Mythical Man Month (Brooks Jr, 1975)
mentions five reasons for disasters being so common, and three of them have to do with estimations
and estimation techniques. His conclusion is that communication is necessary for success. Almost 30
years later, Mike Cohn concludes that “software requirements is a communication problem” (Cohn,
2004). It is clear that technology constantly changes, and so does the customers’ requirements. It is
therefore important that the method used for software development can handle this (Truex,
Baskerville, & Klein, 1999). A family of methods that is said to be able to handle change well is the
agile methods which have emerged from the Agile Manifesto (Beck, et al., 2001). Today they are
frequently used, and most popular is Scrum (VersionOne, 2009-2010).

It is fairly easy to start working agile, and many companies have today adopted some of the agile
methods. One of them is Swedbank IT which begun its agile work in 2007 as a result of the project
“Mer IT för pengarna”. The aim was to become more efficient by decreasing the development time,
doing only the most necessary development and still maintaining the quality. The requirements should
continuously evolve together with a changing world. A new development process was developed to
support the agile way of working, UP-agile, which in brief works as follows:

It starts with Product vision phase, see Figure 1: The development process, UP, compared to the agile
development process, UP-agile., where a product vision is formulated and a business case is written.
In the Agile pre-study, a strategic plan is made, based on requirements, needs and technical
conditions. In Iteration 0, prerequisites for specified deliverance quality for incremental development
are made and secured/assured. IIU, Iterative Increment Development is where the product is planned,
developed, verified and reviewed. In the Delivery phase, the product is prepared for delivery and
finally, in Value realization, the delivered solution is followed up according to the Value realization
plan.

Business need Value

Prestudy Initiate Development Verification Delivery
analysis Realisation

Iterative
Product Agile Value
Iteration 0 Incremental Delivery
Vision Prestudy Realisation
Development

Figure 1: The development process, UP, compared to the agile development process, UP-agile.

One expression used is IKIWISI (I Know It When I See It) which means that new features are
developed to the extent that it is possible to see whether they work or not. The teams should consist of
people with different knowledge, both from the business and the IT departments, working together.

1
However, after working agile for a number of years, the question often arises whether it is possible to
progress further (Poppendieck & Poppendieck, 2010). So is the case with Swedbank IT and the
purpose with this study is therefore to see if the introduction of user stories and story points can help
Swedbank IT make further progress in their agile environments.

The aim with this work is to investigate if the use of story points when estimating can contribute to a
more complete agile process at Swedbank and if the use of story points when gathering requirements
can increase the efficiency of the team and contribute to more accurate estimates. It is also to see if
story points can contribute to an increased collaboration between Swedbank IT and the business side
at Swedbank. This will be done by a literature study and a number of interviews with people working
at Swedbank.

The outline of the thesis is as follows. First, the literature study is presented, and the purpose is to
describe the agile process Scrum, its artefacts and roles. Estimation and requirements gathering are
very central and special focus will be put on describing and explaining the concepts story points and
user stories. Each chapter is finally summarized.

Second, interviews with seven people working at Swedbank are presented. The respondents, who all
have some experience of using Scrum, estimation and requirements gathering, have different roles, as
to give different perspectives on the topics.

Finally, the material from the literature study and the interviews are analysed and conclusions are
drawn on how Swedbank IT may continue their agile work.

2
2 Method
The methods used in this work are a literature study and interviews with a number of people working
at Swedbank IT, all with some experience of requirements and estimation.

Initially, a literature study was conducted where the aim was to first describe one of the most
commonly used agile processes today, Scrum (VersionOne, 2009-2010), its roles and artefacts.
Second, the concepts user stories and story points were defined and described. This literature study
was then used as a starting point for the interview questions. The material was then compiled and is
presented in Chapter 3Agile Software Development.

Interviews with two developers, two Scrum Masters and three Product Owners, all working at
Swedbank, were then prepared. Interviews as method was chosen since this study includes relatively
few respondents and it is of great importance to be able to probe and ask follow-up questions, if
necessary (Oppenheim, 1992). Interviews are also considered the best method for collecting data in
qualitative studies (Yin, 2003).

To be able to structure the interview, an interview guide was developed (Kvale & Brinkmann, 2009).
This was also done to ensure that the same areas were covered in all interviews. One pilot interview
was carried out to test both the questions and the structure of the interview. The interview guide
covered three areas: Scrum, User Stories and Estimation. The aim with the first section, Scrum, was to
give the respondent a chance to present him/herself and to explain his/her role on the Scrum team.
The purpose with the second section, User stories, was to find out how the requirements were
gathered and if there were any problems regarding this. In the third section, Estimation, the questions
focused on how the estimation is done today and if this way of working had changed as they started
working in an agile way.

The interview questions were all open questions to enable the respondents to explain how they work
and give their personal opinions. The same set of questions was asked at all interviews and each
interview was estimated to 30 minutes. The interviews were all recorded and then transcribed and
coded to make it possible to go through the material again. By transcribing and coding the material,
the author is given a chance to get to know the material and also to facilitate the analysis (Dalen,
2007). Three of the interviews were face-to-face interviews and four of them were telephone
interviews. One disadvantage with telephone interviews is that the non-verbal information is lost
(Kvale & Brinkmann, 2009). However, it increases the possibilities of including people who are
geographically distant (Kvale & Brinkmann, 2009).

The results were then analysed and discussed. The questions can be found in Appendix 1: Interview
Guide , a summary of the transcribed interviews in section 6 Results and the analysis in section 7
Conclusion.

3
4
3 Agile Software Development
The software development process is very complex and very hard to predict as it contains so many
variables that are likely to change during the process, such as requirements, time frame and
technology (Abrahamsson, Salo, Ronkainen, & Warsta, 2002). It is therefore necessary to use a
methodology that is easy to adapt to change.

Scrum is an agile development process, see Figure 2: The Scrum process., that focuses on project
management (Schuh, 2005), and like all agile methods, it is based on the Agile Manifesto (Beck, et
al., 2001). These methods value

Individuals and interactions over processes and tools

Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The name “Scrum” comes from a rugby term and was first used in this context in 1986 by Takeuchi
and Nonaka (Takeuchi & Nonaka, 1986). According to a survey carried out by Version One in 2009
(VersionOne, 2009-2010), Scrum is the most common agile method used today.

One of the most important concepts in Scrum is the team, consisting of five to nine people with
different skills that work together during the sprint, another key concept. A sprint is the set time
period during which the tasks are completed. These concepts, as well as other important roles and
artefacts will be described in detail in the following sections.

Figure 2: The Scrum process 1.

1
From http://en.wikipedia.org/wiki/File:Scrum_process.svg (September 30, 2010)

5
3.1 Roles in Scrum
There are three different roles in Scrum: the team, the Scrum Master and the Product Owner, and they
work closely together during the project. A Scrum team usually consists of seven people, plus or
minus two (Miller, 1955). If there are more people on the team, it is recommended to divide them into
multiple teams (Schwaber & Beedle, 2002). The team is cross functional which means there are
people with various skills on the team: designers, testers, developers etc, and they are all needed to
meet the goal of the sprint. However, the team together is responsible for doing the analysis, design,
coding, testing and documentation (Schwaber & Beedle, 2002). The team is also self-organising and
self-managing (Schwaber, 2004). According to Schwaber & Beedle (2002) the synergy effect, when
people with different areas of expertise work together, is an improved code quality and an increased
productivity. It is also possible to use Scrum in larger teams by using so-called Scrum of Scrums
(Cohn, 2010).

Since the team is self-organising and self-managing, there is no traditional project manager in a
Scrum Team. Instead, there is a person called a Scrum Master and the reason he or she is called a
Scrum Master and not a project manager is that Ken Schwaber, one of the co developers of Scrum,
wanted to point out that the role of a Scrum Master is different from that of a project manager
(Schwaber, 2004). The Scrum Master has the role of a door keeper to make sure the team can work
undisturbed during the sprints. The goal is to coach the team so they can perform their best. The
Scrum Master makes decisions and removes impediments identified by the team. Furthermore, he or
she leads the Daily Scrums and is also responsible for the Scrum Retrospectives (Schwaber & Beedle,
2002), both discussed further in section 3.2 The Scrum Process.

The third role in the Scrum Team is the Product Owner, “the provider of a team’s goal” (Cohn, 2010)
which means he or she is responsible for a prioritised list of features called the product backlog. A
product manager or a user department manager may for example serve as Product Owner. Worth
noticing is that the Product Owner is always one single person and never a committee (Schwaber &
Beedle, 2002).

3.2 The Scrum Process

The team, the Scrum Master and the Product Owner work together during a set period of time called a
sprint, see Figure 3 The SprintEach sprint is recommended to last 30 days (Schwaber & Beedle,
2002). However, the length of a sprint may vary from two to four weeks, depending on what is best
for the team (Cohn, 2006).

Figure 3 The Sprint

6
During this period the team work together with focus on set goals, features determined by the product
owner. Since Scrum teams are self-organising, they can organise their work as they see best in order
to achieve the goal, which is to deliver working software at the end of the sprint. No one outside the
team may change the scope of the work during the sprint. However, there are two “mandatory
accountabilities” during the sprint: they have to attend the Daily Scrum meetings and also keep the list
with current tasks, the Sprint Backlog updated (Schwaber, 2004).

Timeboxing is an important feature of agile software development methods and of Scrum which
means that the iterations finish on a set date, even if it means that some of the functionality has to be
dropped (Cohn, 2006). Timeboxing is performed both at release and iteration level. According to
Schuh (2005) there are three major reasons why agile projects should use timeboxing. First, it forces
the customer to decide on what has the highest priority during the iteration. Second, timeboxing
provides a near-term goal which can help the team focus on what is most important at the moment.
Third, timeboxing is a way to ensure that the team will deliver something useful during the sprint.

There are only a few artefacts in Scrum, and one of them is the Product Backlog, see Figure 4 The
Product Backlog, a prioritized list of items that should be carried out during the project. Items on the
Product Backlog include product features and functionality, but also technology and bug fixes,
anything that needs to be done and anything believed to be a good idea for the product.(Schwaber &
Beedle, 2002).

Figure 4 The Product Backlog

Items are added and removed from the Product Backlog and the items are also reprioritised which
means this list is highly dynamic (Cohn, 2010). The Product Backlog does not need to be complete
before work can begin; there just have to be enough items for the first sprint. Anyone can submit
items to this list, but only the product owner can prioritise the backlog. Items at the top of the Product
Backlog have the highest priority and are also the most detailed ones (Schwaber & Beedle, 2002).
Once there are items on the backlog, the Product Owner and the Team together estimate how long it
will take to develop. The estimate is what Schwaber & Beedle (2002) calls a “starting point”. The
estimates will change as more information about the item is received. The team then selects the
amount of features they estimate they can handle during one sprint and these items are then moved
into the Sprint Backlog (Schwaber & Beedle, 2002).

7
 The Product Backlog may be referred to as a list. However, the product backlog is not merely a list,
but can also be used to improve the communication between the product owner and the team (Sundin,
2009:4).

Another artefact in Scrum is the Sprint Backlog, see Figure 5 The Sprint Backlog, which is a list that
contains the items with the highest priorities from the product backlog. (Softhouse Consulting). This
list contains the tasks that the team will work with during the sprint. It also contains the estimates for
these tasks (Schwaber, 2004). A task on the Sprint Backlog should take 4-16 hours to finish and any
larger tasks should be divided into smaller ones (Schwaber & Beedle, 2002). The Sprint Backlog is a
dynamic list and as soon as the team discovers new work required it is added to the list. Unnecessary
work removed is also removed as soon as it is discovered. Only the team can change the Sprint
Backlog, and if for some reason they realise that there are more on the Sprint Backlog than they can
handle, they meet with the Product Owner to decide how to continue.

Figure 5 The Sprint Backlog

The Product Backlog and the Sprint Backlog are both crucial for the project and they are both used
during the Sprint Planning Meeting, a meeting that consists of two parts and takes place at the
beginning of each sprint. In the first part, the aim is to select a Product Backlog, and in the second part
the Sprint Backlog is prepared (Schwaber, 2004).

In the first part of the Sprint Planning Meeting, the team, the Scrum Master and the Product Owner
meet. The Product Owner has prepared the Product Backlog beforehand and the team then selects the
items they believe they can implement during the sprint. In the second part, the team starts to plan the
sprint and discuss how they are going to turn the Product Backlog items into functionality. These
items are then transferred into the Sprint Backlog. This list must not be complete, there only has to be
enough items to get the team started on the sprint. The Product Owner does not participate in this
meeting but must be available to answer questions from the team (Schwaber, 2004)

Communication is very important for a successful project (Brooks Jr, 1975). Since there are only a
few written artefacts in Scrum, much focus is on oral communication. One opportunity to
communicate is at the Daily Scrum, an important feature of Scrum. It is a short (about 15 minutes)

8
daily meeting where each member of the team answers the following three questions (Schwaber,
2004):

• What have you done since the last Daily Scrum regarding this project?
• What will you do between now and the next Daily Scrum meeting regarding this project?
• What impedes you from performing your work as effective as possible?

The answers should be brief and no other topics are discussed. If needed, a follow-up meeting may be
scheduled.

The meetings are led by the Scrum Master and open to anyone interested. However, only members of
the team are allowed to speak. The meeting starts at the designated time, and the Team Members must
make sure they arrive on time (Schwaber & Beedle, 2002). Some teams like to stand up during the
meeting in order to keep them as short and effective as possible (Schuh, 2005). Preferably, the
meetings are held at the same time and in the same room, every day (Schwaber & Beedle, 2002)

There are several goals with Daily Scrum Meetings. One of them is to ensure the priorities of the team
are the right ones. A second one is to keep everyone informed on how the project progresses. Third, it
is a way for the Scrum Master to learn of any obstacles that may be in the way. Finally, it is a way of
tracking the completion of work. (Schuh, 2005)

At the end of each sprint, there is a Sprint Review Meeting, or Sprint Demo as for example Kniberg
(2007) calls it. This is where the team present what they have worked with during the sprint to the
Product Owner, the customer and the management. They then decide how and to what degree
functionality has been implemented, and any work not satisfying is returned to the Product Backlog.
Any functionality that is not “done” cannot be presented (Schwaber, 2004). At the beginning of the
meeting, the team presents the sprint goal. The functionality is then presented, and at the end of the
presentation stakeholders can ask questions and give feedback. This is also where the stakeholders can
accept the results or identify any other desired functionality.

Worth noticing is that the Sprint Review is a working meeting and the team should not spend more
than an hour to prepare a presentation for the meeting (Schwaber, 2004). Focus should be on what the
team has been able to build (Schwaber & Beedle, 2002). According to Kniberg (2007) there are a
number of advantages with having a Sprint Demo:

• the team get credits for the work they have done
• the team actually finishes work instead of leaving it 99% completed
• it is a chance to receive feedback from stakeholders, among others

After the Sprint Review Meeting, the team, the Scrum Master and, sometimes, the Product Owner
meet for a Sprint Retrospective, a meeting time-boxed to three hours (Schwaber, 2004). The aim with
this meeting is to summarize the work with the past sprint and reflect over what can be done
differently in the future.

All team members then answer the questions

• What went well during the last sprint?

• What can be improved in the next sprint?

9
The Scrum Master then summarizes the team’s answer, and together they talk about how they should
work during the next sprint. The Scrum Master does not have the answers, but is there to help the
team to find better ways to work.

A number of different things can be learned from a sprint retrospective. Cohn (2010) writes that many
of them will be related to the product but there will also be much learning about the team and how
they use Scrum, for example the amount of work the team can handle in one sprint, if they achieve
working software at the end of each sprint and how they can increase their efficiency. It is of utmost
importance that lessons are learned from previous sprint since one main feature of iterative and
incremental development is to get feedback, learn from it and then adapt it on the next sprint.

3.3 Summary
Scrum is the most common one of the agile methods. The Scrum team consists of five to nine people
with different skills and it is self-organising and self-managing. There is no traditional project
manager but a Scrum Master who has the role of a gate keeper that should make sure the team can
work without being disturbed during the sprints. A sprint is a set time period during which the team
works with the tasks from the Sprint Backlog, the list of things to do. There is also a Product Owner
who is responsible for the Product Backlog, the prioritized list of tasks.

The team, the Scrum Master and the Product Owner meet for a Sprint Planning Meeting where they
discuss how many tasks from the Product Backlog they can put on the Sprint Backlog. The team then
work with their tasks during the sprint. Every day they have a Daily Scrum Meeting, a short meeting
where everyone on the team tells the others what they have done since last meeting, what they plan to
do today and if there are any impediments. At the end of the sprint there is a Sprint Review Meeting
where the team now demonstrate what they have done and receive feedback from the Product Owner,
the customer and the management. They now decide whether the wanted functionality has been
implemented. Before the start of the next sprint, the team and the Scrum Master have a Scrum
Retrospective Meeting where they evaluate the sprint and talk about how they should work during the
next one.

10
4 Requirements
Requirements are defined as “statements that describe what the software system should be but not
how it is to be constructed” (Tsui & Karam, 2007). These statements are therefore very important
since they describe what the user wants from the system. To gather the requirements in an efficient
way is of utmost importance to the software development process since incomplete requirements
specifications is one of the top reasons for project failure (Tsui & Karam, 2007).

In a traditional waterfall-oriented process there is a cycle of

• writing all the requirements

• analysing the requirements
• designing a solution
• coding the solution
• testing it

It is very common that customers and users are involved at the beginning when the requirements are
written. Then they more or less disappear until it is time to accept the software. that According to
Cohn (2004) this does not yield satisfactory results since customers and users are required to be
involved throughout the whole project. Therefore, they cannot disappear in the middle of the project.
This is something also pointed out by Jones (2007) who states that the top three historical problems
that have affected – and still affects - software projects have to do with changing requirements.

Here, two different ways of gathering requirements will be explained. First, in section 0

Use Cases, the method of gathering requirements by using use cases will be explained. Second,
section 4.2User Stories, will describe how requirements can be gathered by using user stories.

4.1 Use Cases

In 1967, Ivar Jacobsen developed the architecture for Ericsson’s AXE system. In order to get a
general idea of how the system worked, he wrote what he then called usage scenarios. His intention
was to keep them informal as he had found out that people resisted writing them when they became
more formal. In 1987, when he was about to be published in English, he coined the term use case as
he thought it sounded better in English (Cockburn, 2002).

Today, a use case is defined as “A sequence of actions that a system should perform within the
business flow context of the user or the actor.” (Tsui & Karam, 2007). Use cases are requirements
documents that describe behavioural requirements. It is “a prose description of a system’s behaviour
when interacting with the outside world” (Cockburn, 2002). One common way to make the use cases
more concrete is to write scenarios, which is a detailed description of what will happen in a specific
case (Lunell, 2003)

Cockburn (2002) states that there must be several templates for use cases, depending on the teams’
needs. Some are satisfied with the “use case brief” which consists of a few sentences that summarizes
the use case. Other may prefer the “casual use case”, that is, a few paragraphs of text while some need
the “fully dressed use case” with information about stakeholders, business rules and performance
constraints.

However, some people still did not find the use case model formal enough while others found them
too formal. Kent Beck, creator of XP, believed in the idea of informal scenarios and coined the term
user story (Cockburn, 2002).

11
4.2 User Stories
A user story is when a wanted feature is written on a card, expressed in everyday language and it is
often written on the form “As a <type of user> I want <capability> so that <business value> (Cohn,
2010). User stories are composed of three aspects (Cohn, 2004). First, there is a written description of
the story which is used when planning the iterations. Second, not all information is included on the
cards so the written cards are therefore completed with discussions about details. These discussions
take place several times during the project, for example during estimation of stories and at iteration
planning. Third, it is very important that the team and the customer agree on the deliverance.
Therefore, acceptance tests are used to determine when a story has been completed. These three
aspects are called Card, Conversation and Confirmation (Jeffries, 2001).

User stories can be written either or paper or by using a software. Cohn (2006) believes that there are
a number of advantages with having them on paper: it is simple, interaction and discussion are
encouraged and they can be placed, sorted and carried around. However, the main advantage,
according to Cohn (2006), is that due to their “low-tech nature” they work as a reminder that “stories
are imprecise”. A team that is not located at the same place will probably prefer software to cards
(Cohn, 2006).

The card does not include all the details about the stories, but is only a short description of some
functionality. Use cases are much more detailed. The important thing is not the card itself, but the
discussion that takes place between the customer and the developers when talking about the story.
Also, user stories are not meant to be kept after the iteration in which they have been used, as opposed
to use cases (Cohn, 2004).

New stories can be written anytime throughout the project. It might be details expressed as additional
stories, a story too large to fit into one iteration or simply new features added.

User stories are written in normal language and are therefore easy to understand, both for customers
and developers. Since not all information is on the story card, verbal communication is very important
and therefore encouraged. Furthermore, they support iterative development and do also build up tacit
knowledge. According to Cohn (2004) user stories are “beneficial to daily scrum meetings because
they help ensure focus remains on customer and end-user desires”.

In large projects, there might be hundreds or thousands of user stories and it may be difficult to
organise them all. User stories encourage face-to-face communication and conversations and in large
projects written documents may be a more efficient way of communicating (Cohn, 2004).

Sometimes it is necessary to split a user story into two or more stories. The story might be too large to
implement during one sprint. It might also be necessary to split a story if a more accurate estimate is
needed. A large story should however never be split into its constituent tasks since this may lead to
the delivery of some of the tasks but not necessary working software (Cohn, 2006).

Coplien (2009:4) is very critical of user stories as he believes most of them “have neither a user, nor a
story. It’s nerds writing coding requirements. Pseudo-code is back with a vengeance.”. Another critic
of user stories is Dan North who believes that dividing a problem into a number of stories shifts the
focus from actually solving the problem to delivering a large amount of stories. It is also very likely
that there will be a problem as there are so many stories to estimate and it is very likely that people
will “cut corners” when estimating them. (North, 2009)

12
4.3 Summary
Requirements are statements that describe what the user wants from the system should. These
statements can be gathered in different ways. Use cases have been used for many years, but some
people considered them too formal. Instead, they started using user stories where the wanted feature is
expressed on a card in everyday language, often on the form “As a <type of user> I want
<capability> so that <business value> “. One advantage with user stories is that they can be
understood by everyone. They also encourage discussions since not all information is included on the
card.

13
14
5 Estimation
It is impossible to perfectly predict a software development project (Cohn, 2004), but there are a
number of ways to estimate them. It is however important to remember that the process is called
estimation, not exactimation. (Armour, 2002)

It is the responsibility of the stakeholders to prioritise the requirements and the responsibility of the
developers to do the estimating (Ambler, 2009).The user stories should, ideally, be estimated by the
whole team. The reasons for this are, according to Cohn (2004) and (Schuh, 2005) that since it is not
yet known who will do the work, the team should together estimate the story. It is also better to have
estimates from the whole team than from individuals (Jørgensen & Moløkken, 2002). If there are any
estimates the team does not agree on, they are discussed until agreement is reached.
One problem with estimates according to (Cohn, 2006) is that they often become commitments. When
a team gives an estimate of a task, it is often interpreted as a commitment by the stakeholders. It is
important to remember that the estimate is not a commitment but a starting point. Armour (2002)
states that “an estimate is a probability” and it is not possible to make a commitment to a probability,
only to a date. Cohn (2006) claims that it is of utmost importance to separate estimates of size from
estimates of duration. One way of doing this is to use a measure of size that is relative and in a unit
that people do not associate with duration. This is further discussed in section 5.2 Measures of Size.
Another problem, according to North (2009), is that “estimation is fractal”. This means that when
estimation is done in fine detail, the total tends towards infinity since the people estimating multiply
what North calls “the fear factors” into the estimates.

To be able to perform as accurate estimates as possible, it is important to know the team that will
carry out the tasks and how much work they can complete during one iteration. This can be done by
determining the velocity of the team, further described in section 5.1 Velocity. It is also necessary to
have a good understanding of the tasks in order to estimate their size. This can be done in a number of
ways and is described in section 5.2 Measures of Size. One way to determine the relative size of the
tasks is to use Planning Poker and this technique is described in section 5.3 Planning Poker.

5.1 Velocity
Velocity is defined as the amount of work that a team can complete in an iteration and this concept
was introduced by XP (Schuh, 2005). The amount of work can be measured in for example ideal days
or story points, see section 5.2 Measures of Size.

According to Cohn (2006) there are three ways of estimating velocity. Regardless of which method is
used, it is important to give the estimates in a range since there is always a certain amount of
uncertainty. The first alternative is to use historical averages, if there are any. However, one problem
with using values is that very often things have changed from one project to another. It is therefore
important to ask yourself the following questions (Cohn, 2006):

• Is technology the same?

• Is the domain the same?
• Is the team the same?
• Is the product owner the same?
• Are the tools the same?
• Is the working environment the same?
• Were the estimates made by the same people?

15
If the answers to the above questions are ‘yes’, then using historical averages might be an option, If
one or more questions are answered with a ‘no’, historical averages might still be an option but the
velocity must be expressed in a range. This can be done by using “The Cone of Uncertainty”, see
Figure 6 The Cone of Uncertainty. Redrawn from (Little, 2006), a concept first introduced by Boehm
in 1981 (Boehm, 1981). At the beginning of a project, the estimates are very uncertain since little is
known about the project As can be seen in Figure 6, an estimate T made in the initial concept phase
should be treated as a range of (0.25*T , 4*T), while an estimate of T in the design phase should be
treated as a range of (0.9*T, 1.1*T). As the project proceeds and more is known, the uncertainty
decreases.

Figure 6 The Cone of Uncertainty. Redrawn from (Little, 2006)

The second alternative, sometimes called ‘Yesterday’s weather’ (Kniberg, 2007) is to run one or more
iterations and observe the velocity. This is a very good way to predict velocity and is recommended as
the default approach by Cohn (2006). When doing this, it is important to explain to the customer that
this is not done to avoid making estimates, but to avoid giving inaccurate estimates. It may seem like
it takes much time to run a number of iterations before estimating the velocity, but according to Cohn
(2006) it often takes a similar amount of time for developers, analysts and project manager to put
together a traditional project plan. The cone of uncertainty might be used in this approach as well. The
third alternative is to make a forecast and this is very similar to iteration planning. This is useful when
there are no historical averages and circumstances does not allow for observation iterations. The best
way of doing this according to Cohn (2006) is to first estimate the number of hours that each person
will dedicate to the project each day. Then estimate the time available in this iteration. This is done by
multiplying the number of hours available each day by the number of people on the team and the
number of days in the iteration. Finally, expand the stories into tasks and estimate them, then select a
number of stories until the number of hours in the iteration is filled.

16
Cohn (2006) gives the following guidelines on which approach to use:

1. If possible, run one or more iterations before estimating the velocity.

2. Use historical averages from a similar project by the same team.
3. Make a forecast.

It is important to remember to revise the estimated velocity as soon as there is new data from the team
and the project. It is also important to remember to always give the estimates of velocity in a range
since there is always a certain amount of uncertainty.

5.2 Measures of Size

There are a number of ways to quantify the size of a software project. In this section a number of
traditional measures are described as well as some agile measures.

One way of estimating the size of a project is to estimate the number of lines of code (LOC) or
thousand lines of code (KLOC). This approach was used by Boehm (1981) in the constructive cost
model, COCOMO that computes the software development effort as a function of program size,
which is expressed in KLOC.

The concept function points was introduced in the 1980’s and became an alternative to the lines-of-
code metric (Tsui & Karam, 2007). When estimating the size of a software project using function
points, the following five components are considered:

• External inputs
• External outputs
• External inquiries
• Internal logic files
• External interface files

Each component is then given a weight which is based on the described complexity of the project: 3
for simple, 4 for average and 5 for complex. The five components are then multiplied with their
respective complexity. As Tsui & Karam (2007) points out, function points is merely an estimation of
the size of the project and to be able to say something about the effort needed, it is necessary to know
something about the productivity of the team (sometimes referred to as the velocity, see section XX).

One of the ideas with function points is that they should mean the same whoever stated them. There is
an organisation, International Function Point Users Group (IFPUG) providing education and
information about function points (IFPUG: International Function Points User Group, 2010).

5.2.1 Agile Measures of Size

There are a number of ways to measure the size in an agile way. One way to estimate time in agile
projects is to use the quantity ideal time. This measure is based on an estimation of how long this task
would take to complete in “an ideal, interruption-free environment (Schuh, 2005). Cohn (2006) also
introduces the concept of elapsed time, “the amount of time that passes on a clock”. He exemplifies
this with a game of American football, where the ideal time is sixty minutes. However, a game will
take at least three hours due to the many interruptions that occur during the game. In software
development, both ways of measuring time have a purpose, but as Cohn (2006) points out, ideal time
differs from elapsed time due to what he calls “natural overhead”, that is for example meetings, sick
time, email, phone calls, task switching and bug fixing.

17
Cohn (2006) mentions that some of the advantages with measuring time in ideal days are that it is
easy to explain to people outside the team. There is an intuitive feel which makes this concept easy to
understand. It is also easy to use this concept when starting to estimate tasks.

In recent years, however, this concept of ideal days has been abandoned by some people in the agile
world, and other terms like story points are used instead. The reason for this is, according to Schuh
(2005) that some customers and managers had difficulties making a clear distinction between an ideal
day and a calendar day. There are a number of reports on how much time is spent on answering e-
mails, attending meetings and returning phone calls, for instance. Boehm (1981) writes that 70% of
the time is spent on project activities. Cohn (2006) refers to two other reports: one showing that
individuals spend as little as 55% on project activities, and the other claiming that engineers at Toyota
spend 80% of their time on their projects.

One solution to this, according to Cohn (2006), is to think of ideal days as an estimate of size. When
asked how long one task will take, the answer can be converted into calendar days if the team know
how much “natural overhead” they have. Cohn (2006) also recommends that the team agree on one
estimate for each story instead of suggesting a number of ideal days for each individual that will work
on that story. There are two reasons for this. First, it puts the focus on the team instead of the
individuals and second, it decreases the amount of work that has to be done.

One way to measure the size of a user story or a feature is to use story points. In contrast to function
points described in section 4.2.2 Measures of Size, story points are unique to one team. The numbers
does not actually mean anything; they are only a way to describe the size of one feature/user story
compared to another. In other words, story points are relative. It is an estimate that includes the
complexity of the feature, the effort needed to develop the feature and the risk in developing it (Cohn,
2006). The story points do not say anything about when a story will be completed. To estimate the
duration, the number of story points is divided by the velocity of the team.

There are two ways to get started with story points: one is to select the smallest story and to assign the
value of one story point to it, another is to select a medium size story and give it a number in the
middle range (Cohn, 2006). It is then fairly easy to tell if the rest of the stories are smaller or larger
than the chosen one.

Figure 7: An example of the

breeds and the assigned dog
points.
Dog
Breed
Points
Labrador retriever 5
Terrier 3
Great Dane 10
Poodle 3
Dachshund 1
German shepherd 5
Saint Bernard 9
Bulldog 3

Cohn (2006) illustrates the concept of story points with an example where he assigns “dog points” to a
number of breeds of dogs: Labrador retriever, Terrier, Great Dane, Poodle, Dachshund, German

18
shepherd, Saint Bernard and Bulldog, see Figure 7: An example of the breeds and the assigned dog
points.

He defines a dog point as the height of the dog at the shoulder. He starts by giving the Labrador
retriever a 5 as it “seems medium-sized”. He then assigns “dog points” to the other breeds by referring
to the medium-sized Labrador retriever. Cohn’s point is that even if you are not an expert on dogs,
you can arrange them by size, and that you sometimes have to make assumptions or take a guess.

Story points are used to estimate the Product Backlog, but for estimating the Sprint Backlog, Cohn
(2007) prefers hours. The reason for this is that story points is a measure useful in the long term, but
as a short-term predictor, hours are more accurate.

According to Cohn (2006) there are a number of advantages of using story points:

First, they help the team to work cross-functionally. Since the team has to come up
with one number, they all have to agree on one estimate for each user story.

Second, estimates in story points do not decay since they are relative. The most
complex story will still be the most complex story, even if the team’s experience or
technology changes.

Third, story points are a measure of size, not duration. It is easier to estimate that this
story is like that story than to estimate the absolute size of a story. The fact that story
points are an abstract concept, expressing size, does also reduce the risk of comparing
them with reality.

Fourth, teams estimating in story points are often faster at estimating than teams
estimating in ideal time. It takes some time to get used to it, but when the team has
adjusted to this mindset, it is quicker. This opinion is shared by Ljadas (2006).

Fifth, what is one ideal day to one developer or one team is not to another. The
advantage with story points is that they can be compared among team members.

5.3 Planning Poker

Planning poker (Grenning, 2002) is one way to do the estimating, and according to Cohn (2006) it is
reliable. It also has the advantage of involving all participants (Grenning, 2002). All developers (i.e.
programmers, testers, user interaction designers, database experts etc.) of the team participate in
planning poker. If there are more than ten people, the team is divided into two groups. It is also
possible to play Planning Poker with a part of the team, even though this is not recommended (Cohn,
2006).

Planning Poker is played at two different times. It is first used to do the initial estimation, before the
project begins or during the very first iterations. Further into the project, it is used to estimate any new
items that have occurred (Cohn, 2006).

19
Cohn (2006) explains Planning Poker as follows: At the beginning of the game, each person is given a
deck of cards where the cards are numbered for example 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 and 100. There
is also one card with the infinity symbol and one with a question mark.

Figure 8: Planning Poker cards.

The Product Owner reads the item to be estimated and the item is then discussed by the team. If there
are any questions, they are answered by the Product Owner. Each estimator then selects a card
representing his or her estimate. When everyone has selected a card, all cards are turned over
simultaneously for everyone to see. If all cards show the same number, that is the estimate for that
item. If the cards do not show the same number, the people with the highest and lowest estimates give
reasons for their choice. The estimates are then discussed, and after the discussion, new cards are
selected. This is repeated until the estimates have converged.

According to Cohn (2006), there are a number of reasons why Planning Poker works. First of all, in
this game people with different expertise knowledge work together with the estimation. Second,
during the Planning Poker game, there is a discussion on the estimates and also on any missing
information. In agile projects, this is a very important point as the user stories are somewhat vague.
There are also studies that have shown that group discussions of estimates (Jørgensen & Moløkken,
2002) and averaging individual estimates (Höst & Wohlin, 1998) lead to better results. Last, but not
least, Cohn (2006) states that “planning poker works because it’s fun.”

5.4 Summary
Estimation is a difficult but important part of the software development process. One must remember
that it is called estimation, not exactimation. To be able to perform as accurate estimation as possible,
there are a number of things that must be known. One of them is the velocity, that is how much work
the team can perform during one iteration. There are three ways to determine this: by using historical
averages, by running one or more iterations and observe the velocity or by making a forecast.

Another thing that must be known is the size of the project. Previously, size has been measured in
number of lines of code (LOC) or thousand lines of code (KLOC), but today the quantity ideal time is
often used. Some people want to use a measure that has nothing to do with time when they measure
the size and they therefore use the relative measure called story points. Often the Product Backlog is
measured in story points and the Sprint Backlog in hours.

One way to do the estimation is to play Planning Poker, a game played by the whole team. Each task
is estimated by all team members at the same time, and if there is disagreement the extreme values are
discussed until agreement is reached. There are many advantages with this game, one being that
everyone gets the chance to speak. Studies have also shown that group discussions and averaging
individual estimates lead to better estimates.

20
6 Results of the Interview Study
The aim with this work was to investigate if the use of story points when estimating can contribute to
a more complete agile process at Swedbank and if the use of story points when gathering
requirements can increase the efficiency of the team and contribute to more accurate estimates. It was
also to see if story points could contribute to an increased collaboration between Swedbank IT and the
business side at Swedbank. In order to get a clearer view of the practice at Swedbank, an interview
study was carried out. Seven people working at Swedbank with different roles and different
experience of Scrum and user stories were interviewed. Some of the interviews were face-to-face and
some of them were telephone interviews. The seven interviews took approximately 30 minutes each.
The interviews were then transcribed which resulted in 40 pages of text or 22440 words. The material
contains 734 sentences which were then classified according to nine different classes: Tasks, Agile
work, Traditional work, Requirements, Estimation, Advantages, Problems, Improvements and Key
quotations. This was done in Excel and the purpose was to make the material searchable.

The table below shows the seven respondents and their roles:

Respondent Role
R1 Scrum Master
R2 Scrum Master / Project Manager
R3 Developer / Architect
R4 Developer
R5 Product Owner
R6 Product Owner/Project Manager
R7 Product Owner

The seven interviews are here summarised thematically. The interviews were all conducted in
Swedish and the quotations in the text have been translated from Swedish to English by the author.
The numbers in brackets correspond to the original quotations which can be found in Appendix 2:
Quotations in Swedish.

All the interviews followed an interview guide (in Swedish only), see Appendix 1: Interview Guide in
Swedish, and covered two main areas: “Requirements and User Stories” and “Estimation”. For a more
detailed description of the method, see section 2 Method. In section 6.2 Requirements and User
Stories the results concerning requirements and user stories are presented and in section 6.3
Estimation the results concerning estimation are presented. There were also some general comments
on agile work and they are presented in section 6.1 Agile Software Development. The interview study
is finally summarised in section 6.4 Summary.

6.1 Agile Software Development

R5 says that there are a number of advantages when working agile, such as ”everyone working in
these projects thinks it’s more fun” [568], There is also ”a much closer dialogue between business and
IT” [569] and ”the prioritisation becomes very clear and so does the deliveries” [574].

R4 is also very positive to using agile methods: ”The idea of having daily meetings, quick check all
the time it is, I think it is great and keeping the project members and the task together” [491].

21
6.2 Requirements and User Stories
The User stories for a project or a pre-study are usually written during a workshop. R5 explains
”We’ve usually worked in a number of workshops where we’ve first defined the roles and then
defined, set up user stories for each role and different functions, and exit-criteria for these user
stories” [517]. The workshops lasted 2-3 hours and participants were, according to R5 ” the IT Project
Manager and the resources at IT that will work with it, with the delivery, and then it’s been me.”
[522]. R5 estimates that in one project they spent approximately 15 hours on the requirements and he
concludes ”it was very efficient compared to traditional work with requirements/requirements
analysis/gathering” [528].

The User stories are initially written on yellow Post-it notes and then transferred into an Excel
spreadsheet along with exit-criteria according to both R1 and R5.

Traditionally, Use cases are used when gathering requirements. R1 believes that ”People in general
find this rather hard, time consuming and costly” [33]. It is also, according to him, ”very easy that you
can’t think any more when you develop/design use cases.” [35] and he continues “You work so hard
on each use case that … it’s just not a creative process” [36].

R5 says that these use case documents are ”rather detailed, fairly cumbersome documents to work
with where you try to describe the exact appearance and functionality of the system” [532].

R4 says that the requirements have been more or less complete when he has started working on them
and that ”we have along the way worked, worked through and re-worked them from the technical
possibilities and problems that we come across” [388]

6.2.1 Advantages with User Stories

One of the Scrum masters, R1, sees a large number of advantages in working with user stories: ”above
all, I see the advantage that it is easier and not so filled with anxiety” [31]. He also believes that ”user
stories are quicker, it is more fun, you have ... I think you catch more stories/cases this way than
traditionally” [34]. The greatest advantage however, according to R1 is that ”more is discovered, it is
more fun, it is more efficient and you’re not completely knackered afterwards. It’s more like you have
the energy to continue with this” [39]. R2, also a Scrum Master, said that one advantage was that
”everyone in the project is involved and that makes the project visible to everyone.” [155].

R3, one of the developers, thinks that one advantage with working with requirements this way is that ”
you divide, you try to structure the requirements in a logic way like, well, these are the requirements
that belong to this particular function” [269].

The product owners also see a number of advantages with user stories. R5 sees almost only
advantages with this way of working [544]. He says ”It’s a lot quicker to get started with the
requirements and it’s much clearer” [539]. Another great advantage, R5 continues, is that ”in
formulating it from the user’s perspective it becomes more, more customer- and user oriented, which
is a great advantage” [542].

He also points out that ”Furthermore, you don’t have to be used to working with requirements to be
able to start working with user stories ” [540] This view is shared with another product owner, R6: ”It
is very common that you hear when you start talking requirements, gathering requirements and
documenting requirements that ‘But I can’t write requirements’ ” [609]. She describes this way of
working with requirements:” Well, in my experience, the work with requirements becomes fun,
rather, not easy in a negative way but a bit more ... more pleasurable if you may use such a word in

22
this context” [606] and adds that another advantage is that ”you focus, I think, on the right things in
this phase when you work with user stories” [608].

R7 has observed that ” something I have learned from the workshops I’ve led is that there are many
discussions and very good discussions that become very valuable and that’s something that would
never have appeared if people would’ve sat on their rooms writing use cases” [728] R7 also believes
that this is a quicker way to gather requirements, it is ”much less, much more clear, much more
concrete/hands-on and less fudge” [684]. As he sees it, one of the great advantages is that ”it becomes
more fun and more easy to work. It feels less heavy and dull” [611].

6.2.2 Problems with User Stories

There are, however, a number of problems that occur when working with user stories. One major
problem, as R2 sees it is that ”if you have like 300 activities to implement and you then are going to
discuss them all in detail in the group, it takes a very long time” [159]. R1 thinks that they ”don’t have
enough experience to understand what level we should aim at”[51] and continues ”we both need to
read more theoretically and get more experience” [52]

The developers also noticed some problems when using user stories. R3 said ”Earlier, use cases might
have been, it feels as if they have been more technical than user stories, so user stories become more
fuzzy and a bit more general so it became, well it became a challenge now” [235].

One question that has to be solved is how to document and store these user stories. R1 finds this very
important so they can avoid ”the feeling that you’re doing the same things twice. There must be an
agreement on a guideline or a policy” [30]. This is something that the Product Owners also are well
aware of. R6 ”But this is a fairly large question how, if the requirements are gathered this way, do we
still want them in our library with use cases or should there be two, should two types of
documentation be allowed? ” [618].

6.2.3 Improvements
R1 has a number of suggestions on how to improve the work with user stories, for example ”to be
able to formalise it a bit more maybe ” [40] and ” maybe decide that this is the way we should run our
workshops, that there is a template for how the workshops should be run” [41]. He also thinks they
have to ”spread this throughout the organisation” [42]. R2 believes that ”make sure the prerequisites
are there, that is, I as a project manager should set aside some of the budget for the project for these
kind of exercises” [160]. This opinion is also shared with one of the developers, R3:”It is important
that we get the prerequisites needed, also from the business, that they have time for creating quality on
requirements and user stories” [287].

R4 believes that if ”a developer could participate earlier in the project and design use cases or user
stories” [412] the functionality could very easily be improved.. He also stresses the importance of
communication when working agile: ”But above all get the dialogue working a bit earlier, that might
help. Because they are not used to that, but they’re getting better at it ” [415]. R3 also believes that
communication, for example workshops is important ” ”And that they have time for workshops so we
can go through, otherwise we might start working and maybe rush through it in order to not delay the
project” [288]. Another important thing, as R3 points out, is that ”All projects are under pressure,
unfortunately, And I believe the results, the quality of the requirements, that is above all how much
time business have because they often want to push as much functionality as possible” [284][285].

R6 has noticed an increased interest in working with user stories and believes that ”at the moment
there’s a lack of, I think there’s one person who has taken a few courses on how to write, gather

23
requirements this way, so that’s one thing needed. I notice when I talk to colleagues that there’s an
interest in trying to gather requirements this way. So that’s one thing, raising the level of competence
on how to write and document user stories” [612][614]. R6 also finds it important to ”dare to try this
new way and maybe even dare to hold on to not over-documenting later on” [616].

R7 believes that they are doing well in their work with user stories, but they need more practice since
”it takes great skills to write good stories” [688].

24
6.2.4 Summary of Requirements and User Stories
The material from the interviews concerning requirements and user stories are here condensed even
further in order to make the material more lucid.

Scrum Masters Developers Product Owners

Stated • Easier • Requirements • Quick start
advantages with • More effective structured in a logic • More customer-user
agile • More fun way oriented
requirements • Costs less • No previous experience
• Involves everyone required
• Fun
• Focus on important
things
• Valuable discussions
• Quicker way to gather
requirements
Stated problems • Discussions where • More general than • Documentation
with agile the whole team Use cases previously
requirements participate take used.
gathering time
• Lack of experience
to write them at
right level
• How should they be
documented? /Lack
of guidelines
Suggested • Formalise the • Prerequisites needed. • Increase competence
improvements workshops • Time from business level on how to write
to agile • Spread to rest of people to ensure user stories
requirements organisation quality on • Dare to try working
gathering • Make sure the requirements this way
prerequisites are • Involve developers • Sticking to not over-
OK. earlier in process documenting later on.
• Better
communication,
earlier

25
6.3 Estimation
Today the projects are estimated in hours. The estimation is according to R1 and R5 done on two
different occasions: first ”when estimating the price of the project and trying to include all activities
roughly , maybe up to 80 hours level, and then you estimate them” [54] and second ”it is when we
estimate or put the requirements into the sprint backlog and estimate them, that is we break them
down into activities and estimate the activities” [59].

R1 says that the first estimation is usually done by ”the architect writing the pre-study, or the
architectural description, and then we usually take in one more person. I usually take in one more
person just to get some kind of distribution” [64] [65].

R2 says that when they estimate they have a template that ” is based on statistics. It takes X hours to
build an average-sized module” [173]. One of the Product Owners, R5, says that “Well, traditionally
at IT they usually say that if the systems are reasonably well-known, the accuracy is very high. At
business side, I’d say that the accuracy is fairly rough” [560][561].

R6 explains that as a Product Owner she sits in on Sprint Planning Meetings ”We’ve so to say sat with
the others at the table and maybe more listened” [627] when ”The scrum team do the estimating”
[628].

6.3.1 Advantages with Agile Estimation

One thing that works well, according to R1, is when ”we estimate or take the requirements into the
sprint backlog and estimated them, that is, we break them down to activities and estimate the
activities. There we have access to the whole team and we do poker planning” [59][60]. This is
something that one of the developers, R4 agrees on ”Just the fact that we divide it into sprints and
smaller tasks makes it easier to estimate”[428]. He also appreciates that ”there’s a better check-up.
Now you see that, oops, what was it that made this small task took so long, which gives a faster
feedback to this memory bank of bitter experiences” [454][455].

R6 also sees advantages with agile estimation ”what’s good when you’re trying to estimate and you’re
doing Scrum is that you take a few requirements at a time so that there’s not too much at once and
then the chances increase that it’s on target so to speak, that the estimates are more exact” [637].

Another advantage, says R4, when the whole team estimate is that ”When there are more people
there’s often many who have … someone is a time optimist and someone has done something similar
and then you can all help out” [481].

R3 says that ”And it’s very interesting, it often comes up that you maybe have different views of what
this activity means” [321] and continues ”and that’s very good because then we can clarify the
activities. So you really, so everyone knows what it means” [322][323].

When they estimate, they often use planning poker, something that R7 finds really useful since ”it’s a
fantastic way of making everyone speak, I should add. Because that’s very important” [726][727].

R5 also explains that they ”work a lot with the prototype already in the pre-study phase, something
that has led to ”a clearer image of the requirements” [565].

One of the advantages, says R1, is that ”Well, what we do is that we have an extra eye on the cost for
each sprint. We know exactly what each sprint will cost, in principle, since we … the estimates have
been quite good in the sprint backlog” [78][79].

26
R3 believes that ”Well, an accurate estimation of the backlog should of course give better results”
[367]. R7, one of the Product Owners, says ”I think we’ve got a more clear estimate than earlier”
[717] but he also says that ”I can’t say whether the estimates have become better or worse. I think too
little time has passed” [719] but ”I think, in the long run, the estimates will also become much better”
[722].

6.3.2 Problems with Agile Estimation

One problem with this way of estimating, claims R1, is that ”If you’re unlucky, the team think this
costs much more money than those who estimated the pre-study did” [61]. They have never,
according to R1,”estimated everything, that is, the whole product backlog at once. But I know some
people do” [88]. He reflects over the fact that ” I wonder how … what’s best practice? Is it OK to
have a price for the whole project and then estimate the parts the way you should? Or is it better to sit
down and estimate the whole product backlog? Then you should come up with the price of the project
but ... well, that’s an interesting question” [89].

R2 thinks that the greatest problem with this way of estimating is that ”It costs more to do the
estimating this way in having 20 people sitting in X workshops, at 2-3 hours each. And that’s an extra
cost for the project” [190]. Another problem, he continues, is that ”When it’s calm and there are no
deadlines fast approaching, then it’s easier, but when it’s close to a deadline, then you really have to
really feel that this is worth spending time on. Because when everyone’s stressed out, no one feels like
sitting down for three hours talking about how much time something will take, then it’s more like let’s
do it” [194][195].

One of the developers, R3 explains that ”And then you take on 105 hours of stuff and for some
strange reason you deliver each note at the number of hours that’s on the note, but you still can’t make
it. And when you start analyzing it, you often find that you’ve done other things” [355][356].

Another problem, according to R7, is that the resources are asked for “10% here, 10% there, 20%
there” [696] and when working agile “you are dependent on having the same people working, well,
nearly 100% with something” [695].

6.3.3 Improvements
R1 reflects over the first estimation and thinks that one way to improve would be to ”I wonder if it’s
better to use more people and use poker planning to get a distribution of the estimates, a distribution
of the competences of the resources, to get a better mix so to say” [58].

According to R1, they are doing well in the second estimation. However, R1 believes that one way to
improve the estimation is to ”already during the pre-study think about who will implement this so you
can have the same team estimating the pre-study and then implementing the project and estimate these
activities in the sprint backlog. Then it should be more accurate” [63].

R2 believes that one way to improve would be to ”write down guidelines for ‘remember this when
estimating’, such as ‘You must test the modules, you must check in the code, you must write the
documentation and automated test cases’ and things like that” [192].

R3 explains that ”Well, there are always things that you couldn’t predict that we’ll have to test this or
we’ll have to build that, or that something makes a fuss ... IT always makes a fuss, that’s the
definition” [357] and tries to come up with a solution ”So, I don’t know if you just add a larger
percentage of air, but that’s also kind of boring” [358].

27
According to R7 ”Well, it’s back to the fact that this is still in its infancy so we have to be better at
practising this I think” [729] and he therefore suggests that they should ”Put into practice, make use of
our knowledge, find ways that work for us” [730]. He also believes that they will have to “like, spread
the message here”[ 733].

6.3.4 Summary of Agile Estimation

The material from the interviews concerning agile estimation is here condensed even further in order
to make the material more lucid.

Scrum Masters Developers Product Owners

Stated advantages • Whole team work • Easier when divided • Clearer estimates
with agile together into smaller • Everyone is given
estimation • Activities are broken activities. the chance to
down into smaller • Faster feedback. speak.
ones. • Helps being a team • Increases the
• Knows the cost for with different chances of good
each sprint experiences. estimation when
• Discussion and focussing on a few
clarification of requirements at a
requirements. time.
Stated problems • Different teams • Often other things • Resources are
with agile estimating the pre- must be done during asked for from
estimation study and the sprints the sprint. many different
may come up with sources.
different estimates.
• More expensive when
many people spend
many hours on
estimating.
• When a deadline is
approaching it is
difficult to take the
time to sit down.
Suggested • Using more people, if • Need more
improvements to possible from the team practice.
agile estimation to get more exact • Find ways that
estimates. work for the
• Use poker planning. project/ Swedbank.
• Striving to have the • Spread the word
same team estimating
the pre-study and the
sprints.
• Setting up guidelines
on what to think about
when estimating.

28
6.4 Summary
Seven interviews were conducted with Scrum Masters, Developers and Product Owners, all working
at Swedbank. They all saw a number of advantages with agile requirements: it is more fun, everyone
is involved and it requires no previous experience. It is also a quicker way to gather requirements.
There are however some problems, mainly concerning documentation. Some suggested improvements
are to involve the developers earlier in the process and to increase the competence level when it
comes to for example user stories.

They also saw a number of advantages with agile estimation. For example it increases the chances of
good estimates when focus is on a few requirements at a time. The whole team works together and
there are discussions and clarifications of the requirements. It is also a way to get faster feedback. One
of the problems mentioned was that different teams estimated the pre-study and the sprints, something
that might lead to different estimates. One solution that was mentioned was to strive to have the same
team performing the estimates in the pre-study and the sprint. A guideline on things to remember
when estimating was also one suggested improvement.

29
30
7 Conclusion
The aim with this thesis is to investigate if story points can contribute to a more complete agile
process and if the use of story points can increase the efficiency of the team and contribute to more
accurate estimates. It is also to see if story points can contribute to an increased collaboration between
Swedbank IT and the business side at Swedbank.

Based on the literature study and the interviews, it is possible to draw the following conclusions:

Story points can contribute to a more complete agile process since Swedbank today work agile by
using Scrum. They have started using user stories when gathering requirements and the introduction
of story points would to take it one step further.

Story points can increase the efficiency of the team because if the whole team take part in the
estimation they will have a better understanding of the tasks that have to be carried out and the
amount of unnecessary work done will be reduced.

Literature shows that the more people that take part in the estimation process, the better the estimate
will be. Also, the estimates will also be better if done by the same people that will do the
implementation later.

However, including the entire team in performing estimates may cause increased project costs. This
has not been considered in this study.

When working with user stories and, to some extent, story points, the discussions are held at a non-
technical level. This makes it possible for non-technical people to take part and to contribute.

Thus it is possible to conclude that the introduction of user stories and story points can take the agile
process at Swedbank IT further.

Another question raised during the interviews was the documentation. Today, it is an open question
how the user stories should be documented and stored. Some of the respondents were worried that
they would have to document the user stories on the use case format, which means that some of the
advantages with using user stories are lost.

Story points can make the estimation easier for the team, but they might also be of help to the product
owners when prioritising items in the product backlog. When the estimates become visible, it is easier
to choose which item to give the highest priority. For example, if the tasks are of equal priority to the
product owner, story points can help by showing that during this sprint, the team can develop a value
of 10 points. This could either be this one task of ten points or these two tasks of three and seven
points. Thus it is clear to the product owner that he/she can choose either to get one or two tasks
implemented during the next sprint.

Last, but not least, the people who today work agile seem very pleased with it, they even say it is fun!
This view on agile work was also found in (Georgsson, 2010). In my humble opinion, this is a strong
argument for letting interested people try the agile way of working, where possible.

31
32
8 Discussion
The aim with this work was to see if story points could take the agile process any further. No
consideration has been taken to the economic aspects on project management, including training of
staff. However, during the work a number of interesting things were noticed.

There seems to be a quite large interest in agile methods at Swedbank today, even though there are
relatively few agile projects, and this should be taken care of. Those interested in working agile
should be supported and encouraged. During the interviews it appeared that especially user stories
were of interest. However, the respondents were concerned of the fact that so few people were
actually trained for gathering requirements this way. Some kind of formal training would be one way
of meeting their concerns.

The interviews were all conducted in Swedish since all participants were native Swedish speakers.
The quotations used were then translated into English. There is always a risk in translating quotations,
but I believe that the interviews were better if done in Swedish, that all respondents could express
themselves more freely. Therefore, I chose to translate the material I used for the thesis. The original
quotations can be found in Appendix 2: Quotations in Swedish.

The interview questions asked were the same for all respondents. In retrospect, it is clear that the
questions to the product owners should maybe have been formulated differently since the estimation
during the sprint is done by the team themselves.

One very important aspect of the software development process is testing. This has not been covered
in this thesis, but it would be very interesting to see how testing is incorporated in an agile
environment, for example by using Test Driven Development, TDD (Beck, 2003).

33
34
9 Bibliography
Abrahamsson, P., Salo, O., Ronkainen, J., & Warsta, J. (2002). Agile Software Deveopment Methods.
VTT Publications .

Ambler, S. W. (2009). Agile Requirements Change Management. Retrieved October 4, 2010, from
Agile Modeling: http://www.agilemodeling.com/essays/changeManagement.htm

Armour, P. (2002). Ten Unmyths of Project Estimation. Communications of the ACM 45 , no 11:15-
18.

Beck, K. (2003). Test Driven Development: By Example. Boston, MA: Addison-Wesley.

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A., Cunningham, W., Fowler, M., et al. (2001).
Manifesto for Agile Software Development. Retrieved October 12, 2010, from Manifesto for Agile
Software Development: http://agilemanifesto.org/

Boehm, B. (1981). Software Engineering Economics. Prentice Hall.

Brooks Jr, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Addison-Wesley.

Cockburn, A. (2002, January 01). Alistair Cockburn. Retrieved December 09, 2010, from
Alistair.Cockburn.us|Use cases, ten years later:
http://alistair.cockburn.us/Use+cases%2c+ten+years+later

Cohn, M. (2006). Agile Estimating and Planning. Upper Saddle River, NJ: Pearson Education .

Cohn, M. (2007, November 07). Mike Cohn's Blog - Succeeding with Agile. Retrieved October 26,
2010, from Why I Don't Use Story Points for Sprint Planning:
http://blog.mountaingoatsoftware.com/why-i-dont-use-story-points-for-sprint-planning

Cohn, M. (2010). Succeeding with Agile. Boston, MA: Pearson Education.

Cohn, M. (2004). User Stories Applied for Agile Software Development. Boston, MA: Pearson
Education.

Coplien, J. (2009:4). Lean Deconstruction. Lean Magazine , 18-19.

Dalen, M. (2007). Intervju som metod. Malmö: Gleerups.

Georgsson, A. (2010). Agila metoder - en kartläggning av teori och praktik. Umeå University:
Department of Computing Science.

Grenning, J. (2002, April). Published Articles. Retrieved October 20, 2010, from Object Mentor:
http://www.objectmentor.com/resources/publishedArticles.html

Höst, M., & Wohlin, C. (1998). An Experimental Study of Individual Subjective Effort Estimations
and Combinations of the Estimates. 20th International Conference on Software Engineering
(ICSE'98) , 332-339.

IFPUG: International Function Points User Group. (2010, October 01). Retrieved October 12, 2010,
from IFPUG: International Function Points User Group: http://www.ifpug.org/

35
Jeffries, R. (2001, August 30). Cards, Conversation and Confirmation. Retrieved October 19, 2010,
from xProgramming.com: http://xprogramming.com/articles/expcardconversationconfirmation/

Jørgensen, M., & Moløkken, K. (2002). Combination of Software Development Effort Prediction
Intervals: Why, When and How? Proceedings of the 14th international conference on Software
engineering and knowledge engineering , 425-428.

Kniberg, H. (2007). Scrum and XP from the Trenches. Retrieved March 26, 2010, from InfoQ:
http://infoq.com/minibooks/ scrum-xp-fromthe-

Kvale, S., & Brinkmann, S. (2009). Den kvalitativa forskningsintervjun. Lund: Studentlitteratur.

Little, T. (2006). Schedule Estimation and Uncertainty Surrounding the Cone of Uncertainty. IEEE
Software , 48-54.

Ljadas, M. (2006, June 20). Poängen med poäng. Retrieved September 16, 2009, from Citerus:
http://www.citerus.se/kunskap/pnehm/pnehmartiklar/poangenmedpoang.5.1300a18510bea4a5523800
0170.html

Lunell, H. (2003). Fyra rundor med RUP. Lund: Studentlitteratur.

Miller, G. A. (1955). The Magical Number Seven, Plus or Minus Two Some Limits on Our Capacity
for Processing Information. Psycholoical Review,Vol.101, No.2 , 343-352.

North, D. (2009, July 01). The Perils of Estimation. Retrieved 10 11, 2010, from DanNorth.net:
http://blog.dannorth.net/2009/07/01/the-perils-of-estimation/

Oppenheim, A. (1992). Questionnaire Design, Interviewing and Attitude Measurement. New York,
NY: Continuum.

Pew Research Center. (2007, October 04). Pew Global Attitudes Project. Retrieved October 27, 2010,
from Pew Global Attitudes Project: http://pewglobal.org/2007/10/04/world-publics-welcome-global-
trade-but-not-immigration/

Poppendieck, M., & Poppendieck, T. (2010, June 01). On Lean Software. (M. Bria, Interviewer)

Schuh, P. (2005). Integrating Agile Development into the Real World. Hingham, Massachusetts:
Charles River Media.

Schwaber, K. (2004). Agile Project Management with Scrum. Redmond, Washington: Microsoft
Press.

Schwaber, K., & Beedle, M. (2002). Agile Software Development with Scrum. Upper Saddle River,
NJ: Prentice Hall.

Softhouse Consulting. (n.d.). Scrum in Five Minutes. Retrieved September 30, 2010, from Scrum in
FIve Minutes: http://www.softhouse.se/download

Sundin, O. (2009:4). Dealing with the Product Backlog. Lean Magazine , 13-17.

Takeuchi, H., & Nonaka, I. (1986). The new new product development game. Harvard Business
Review , 137-146.

36
Truex, D. P., Baskerville, R., & Klein, H. (1999, Augusti). Growing Systems in Emergent
Organizations. Commun. ACM 42 , pp. 117-123.

Tsui, F., & Karam, O. (2007). Essentials of Software Engineering. Sudbury, MA: Jones and Bartlett
Publishers.

VersionOne. (2009-2010). VersionOne. Retrieved October 12, 2010, from VersionOne:

http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf

Yin, R. (2003). Case Study Research: Design and Methods. Thousand Oaks, CA: Sage Publications.

Zirn, T. (2010, mars 30). Mjukvara dold jätteindustri. Retrieved October 27, 2010, from Computer
Sweden: http://www.idg.se/2.1085/1.306666/mjukvara-dold-jatteindustri-inom-svensk-it

37
38
Appendix 1: Interview Guide in Swedish

Frågeguide
Agilt arbete/Scrum

1. Vilken roll har du i Scrumteamet?

User stories

2. Arbetar ni med user stories?

3. Vilka är fördelarna detta sätt att arbeta?
4. Vad skulle kunna förbättras i detta arbete?

Estimering

5. På vilket sätt sker estimeringen idag?

6. Hur har arbetet med estimering förändrats sedan ni började arbeta agilt?
7. Ser du några problem med sättet ni använder idag för att estimera?

39
40
Appendix 2: Quotations in Swedish
30 ”att man inte känner att man dubbeljobbar. Så att, ja, där måste man ju komma fram till en,
till en riktlinje så att säga, eller en policy.”
31 “Jag ser fördelarna att, framför allt ser jag ju fördelen att, att det är enklare och inte lika
ångestfyllt på något sätt”.
33 “Och gemene man tycker att det är ganska jobbigt, tidskrävande och kostsamt”.
34 ” User Stories går ju fortare, det är roligare, man har … jag tror att man fångar fler fall med
det här sättet än traditionellt
35 ”Det är lätt att man låser sig när man tar fram Use Cases.”
36 ”Man jobbar så hårt med varje Use Case att man … det är liksom ingen skapande process.”
39 ” Så att den största fördelen är att mer kommer fram, det är roligare, det är mer effektivt, det
är mindre kostsamt och man liksom är inte helt slut efteråt utan snarare så att man har energi
att fortsätta med det här och liksom…så
40 “kunna formalisera det lite mer kanske”
41 ”man bestämmer sig kanske att så här borde vi köra workshopparna, att det finns en färdlig
mall för hur man kör workshopparna
42 ” Det vi måste göra också är ju att sprida det här i organisationen
51 ” har vi för lite erfarenhet tror jag för att förstå på vilken nivå vi ska lägga oss”
52 ” vi måste dels läsa på mer teoretiskt och få erfarenhet av.”
54 “när man estimerar priset på projektet och försöker få med alla liksom ganska grova, alltså
upp till, kanske 80 timmars nivå på, på aktiviteterna och sen så estimerar man det”
58 “Men jag undrar om man inte har igen det att man tar in någon fler och liksom använder sig
av poker planning så att man får en spridning på estimatet, en spridning på resursernas
kompetens, så att det blir lite mer blandat så att säga.”
59 ” det är ju när vi estimerar eller tar in kraven i sprint backloggen och estimerar dem, alltså
bryter ner dem till aktiviteter och estimerar aktiviteterna.”
59 “det är ju när vi estimerar eller tar in kraven i sprint backloggen och estimerar dem, alltså
bryter ner dem till aktiviteter och estimerar aktiviteterna.”
60 Där tillgår vi ju, har vi ju tillgång till hela teamet och vi kör med poker planning kort.
61 “Har man otur så tycker teamet att det här kostar mycket mer pengar än vad de personerna
som estimerade förstudien tyckte.
63 “redan i förstudien funderar på vilka implementerar det här så att man får samma team som
estimerar i förstudien som sedan ska implementera projektet och estimera de här
aktiviteterna i sprint backlogen. Då borde det bli mer rätt.”
64 “Ja, det är oftast arkitekten som skriver förstudien, eller som skriver arkitekturbeskrivningen
och sedan brukar vi bara ta in en person. ”
65 ”Jag brukar ta in en person till bara för att få någon typ av spridning liksom.”
78 “Ja, alltså det vi gör det är ju att vi håller ju stenhård koll på hur kostnaden för varje sprint
så att säga.”
79 Vi vet precis vad varje sprint kommer att kosta i princip i och med att vi, estimaten har ju
oftast varit ganska bra i sprint backloggen då.
88 ” Vi har inte, hittills har vi aldrig estimerat allt som ska göras, alltså hela product
backloggen på en gång. Men jag vet att vissa gör det.”
89 ” Där undrar jag också hur, hur man, vad som är best practice på något sätt. Är det okej att
göra så att man har en prislapp på hela projektet sen så estimerar man bara varje del som
man ska göra? Eller är det bättre att man väl sätter sig ner och så estimerar man hela product
backlogen? Då borde man ju komma fram till projektets prislapp då, men ja…det där är ju
en intressant fråga.”
155 “att man involverar alla i hela projektet så att hela projektet blir synligt för alla.” .
159 “har man liksom 300 aktiviteter som ska genomföras då att diskutera alla dem i detalj i
helgrupp det tar väldigt lång tid.” .
160 ” se till att förutsättningarna finns för att, att köra, dvs att man skulle då, så att jag som
projektledare kanske i så fall skulle så att säga lägga en del av budgeten för projektet för den

41
 här typen av övningar.”
173 “Och den estimatmallen kan man väl säga är byggd på statistik. Det tar X timmar att bygga
en medelstor modul liksom.”
190 “Och sen så kostar det ju mer att estimera på der här sättet i och med att man har 20 pers så
ska 20 pers sitta i X antal workshops à 2-3 timmar. Och då blir det ju en extrakostnad för
projektet.”
192 “För sen finns det ju också, kan man ju sätta upp riktlinjer för ”Tänk på det här när du
estimerar liksom” Du ska ha modultestat, du ska ha checkat in koden, du ska ha
systemtestat, du ska ha skrivit dokumentation och automatiska testfall och liksom sådär.”
194 ” Men, och sen så är det ju så att när det är lugnt, man inte har några deadlines ganska snart
sådär, då går det bättre men när det blir nära deadline då gäller det att verkligen känna att
det här är värt att ta tid för det här. ”
195 För då är alla stressade och då har ingen lust att sitta ner i tre timmar och liksom diskutera
hur lång tid någonting tar och då är det liksom bara nu köttar vi på.
235 “För tidigare så, användningsfall kanske har varit, det känns som om de kanske har varit lite
mer tekniska än user stories, så att user stories blir lite luddigare i kanterna och lite mer
generella så att det blev, ja det blev en liten utmaning nu.”
269 “att man delar in, man försöker som strukturera kraven på ett logiskt sätt att, ja, de här är de
krav som tillhör just den här funktionen”
284 ” Alltså alla projekt är ju pressade, tyvärr. ”
285 ”Och jag tror resultatet, kvalitén på kraven det är ju hur mycket tid har framför allt
verksamheten för det är ju de som ofta vill trycka ut så mycket funktion som möjligt.”
287 ” Och då om, då gäller det ju att vi får de förutsättningar som behövs, även från
verksamhetssidan, att de har tid att verkligen göra kvalitet på krav och user stories.”.
288 ” Och att de har tid för workshops så att vi kan gå igenom, för annars kanske det kan bli det
här att vi jobbar på litegrann för att komma igång och som springer för att inte försena det
här projektet.”
321 ”Och det är ju intressant, ofta kommer det ju upp då att man kanske har olika bild av vad
den här aktiviteten innebär.”
322 ” och det blir ju bra för då kan vi ju förtydliga aktiviteterna
355 ” Och så tar man in 105 timmar grejer och av någon skum anledning så levererar man varje
lapp på de timmar som det står på den, men ändå så hinner man inte riktigt.
356 Och när man börjar analysera det här så är det ofta att man har gjort andra saker.”
357 ” Alltså det kommer ju alltid grejer som man inte har kunnat förutse att det här måste vi ju
testa eller det här måste vi ju bygga eller det strular … IT strular ju alltid, det är ju
definitionen.”
358 ” Så jag vet inte, att man, och det är som svårt om man ska bara lägga på en större
procentsats luft, men det känns ju tråkigt också.”
367 ”Sen borde förstås en noggrann backlogestimering ge bättre resultat tycker man ju.
388 “Sen har det blivit att vi har på vägen jobbat, jobbat igenom och jobbat om dem utifrån de
tekniska möjligheter och problem som vi stöter på”
412 ” någon utvecklare får vara med lite tidigare i projektet och liksom vara med och ta fram
användningsfall eller user stories.
415 “Men framför allt det att man får igång dialogen lite snabbare, det som skulle kunna
underlätta. För de är inte vana det alla gånger men det börjar bli bättre.”
428 ”Men just det att vi styckar upp det i, i sprintar och mindre uppgifter då blir det ju lättare att
tidsuppskatta.”
454 ” man har ju mer koll på det Nu ser man att oj, vad var det som gjorde att det, just den här
lilla grejen tog så lång tid, vilket ger en snabbare återkoppling till den här minnesbanken
med bittra erfarenheter. ”
481 “När man är flera så är det ju ofta flera som har … någon är tidsoptimist och någon har gjort
något liknande och så kan man hjälpas åt.”
491 ” Men idén att ha dagliga möten, snabb koll hela tiden den är, den tycker jag är jättebra och
hålla ihop projektmedlemmar och uppgiften.”

42
517 “Vi har gjort så att vi har jobbat i ett antal workshops där vi har först definierat rollerna och
sen definierat, satt upp user stories för respektive roll och olika funktioner och så där och
klarkriterier till de här user storiesarna också.”.
522 ” Alltså dels har det varit IT-projektledaren och de resurser på IT som ska jobba med det,
med leveransen, och sen har det varit jag.”.
528 ” Så det var väldigt effektivt jämfört med traditionellt kravarbete.”
532 Ganska detaljerade, rätt så tungjobbade dokument när man i text försöker beskriva exakt
utseende och exakt funktionalitet i systemet.
539 “Det går mycket snabbare att komma igång med kraven och det är mycket tydligare.
540 ” Man behöver dessutom inte vara van vid att jobba med kravför att kunna börja jobba med
user stories.”
542 ” i och med att man formulerar det utifrån användarens perspektiv också så blir det mer, mer
kund- och användarorienterat, vilket är en stor fördel.”
544 Så jag ser nästan enbart fördelar med det här sättet att jobba.
560 ” Alltså på IT brukar man traditionellt säga att om det är hyfsat kända system så har man
väldigt hög precision.”
561 På verksamhetssidan skulle jag säga att precisionen är ganska grov
564 ” jobbar mycket med prototypen redan i förstudiefasen.”,
565 “det har fått en tydligare bild av kraven har man ju haft.”
568 “ alla som jobbar i de här projekten tycker att det är roligare.”
569 “Det är en mycket tätare dialog mellan verksamheten och IT”
574 ” Sen blir det också en väldigt tydlig prioritering, men det är ju framför allt sen i
genomförandedelen som det blir väldigt tydligt att man, när vi prioriterar och det blir väldigt
tydliga leveranser också.”
606 ” Ja, min erfarenhet är ju att kravarbetet blir roligt, ganska, inte lättsamt på ett negativt sätt
utan … men lite mer lustfyllt om man kan använda ett sånt ord i de här sammanhangen.”
608 ” man fokuserar tycker jag på rätt saker i det här skedet när man jobbar med user stories.”
609 ” Och för det många när man börjar prata krav att man ska fånga krav och dokumentera
krav framför allt att ”Nej men jag kan inte skriva krav” är ofta en, en synpunkt man hör..
611 “en stor fördel tycker jag dels att det blir roligt och lite mer lättarbetat. Det känns mindre
tungt och trögt.”
612 “just nu finns det ju en brist på, jag tror det finns en person som har gått ett par kurser kring
att skriva, fånga krav på det här sättet, så att det skulle ju behövas för det finns ett intresse
märker jag när jag pratar med kollegor av att pröva att fånga kraven på det här sättet.”
614 ”Så att det är ju en sak, att höja kompetensnivån inom just hur man tar fram,
dokumenterar user stories.” .
616 ” Och sen att man vågar, vågar pröva det här nya sättet och, och kanske även vågar
hålla fast vid att inte överdokumentera i ett senare skede heller.”
618 “Men, men det är ju en ganska stor fråga hur, om man ska så att säga, hur dom här, om man
fångar kraven på det här sättet, vill vi ändå ha in det i vårt bibliotek med användningsfall
eller, eller ska man ha liksom två, ska man tillåta två typer av dokumentation?”
627 ” Så det, där har vi ju suttit med så att säga, kanske mer lyssnat då.”
628 ” Så det är ju scrumteamet som uppskattar det.”
637 “det som är bra när man försöker tidsuppskatta och jobbar scrum det är ju att man, att man
tar några krav i taget så att det inte blir så mycket åt gången och då ökar ju chansen att det
blir, att det träffar rätt så att säga, att det blir mer exakt i in tidsuppskattning”
684 “Det blir mycket mindre, mycket mer tydligt, mycket mer konkret och mindre flum blir det.
688 “det är ändå liksom en liten konst det här att, att kunna ta fram bra stories.”
695 ”När man i då om man tänker sig i Scrum eller vilken agil metod som helst så är man
ganska beroende av att det är samma personer som sitter, ja, nästintill 100% i alla fall med
någonting så att det här ska bli någonting och just för att det heter ju team också”

43
696 ”Men hos oss så, ja, projektresurser kan ju vara äskade 10% här, 10% där, 20% där. Det är
mycket liksom… nej det går mycket tid.”

717 ” Jag tror att vi har fått ett tydligare estimat än vad man fick innan.
719 ” Sen kan jag inte säga ifall estimaten har blivit bättre eller sämre, det tror jag det gått för
lite tid.”
722 ” jag tror att på sikt så kommer nog estimaten blir mycket bättre också.”
726 “Och det är ju ett fantastiskt bra sätt att få alla att komma till tals, ska vi väl tillägga. För det
är jätteviktigt.”
728 ”Och det är ju också något som jag kan ta med mig från de workshops som jag har haft just
att det är mycket diskussioner och väldigt bra diskussioner som blir väldigt värdefulla och
det är sånt där som aldrig skulle ha kommit fram om man hade liksom suttit på sin kammare
och gjort användningsfall.
729 ” Nejmen det är väl tillbaks litegrann igen till att det är ju i sin linda litegrann det här så att
vi måste bli bättre på att praktisera det här tror jag.”
730 ” Praktisera, tillämpa, hitta sätt som funkar för oss.”
733 ” det är liksom sprida budskapet här.”

44