HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE

Facilitating Knowledge Sharing and Embodiment, and Making Architectural

Changes Visible

Rolf Njor Jensen, Niels Platz and Gitte Tjørnehøj

Institute of Computer Science, Aalborg University, Fredrik Bajersvej 7E, Aalborg, Denmark

Keywords:

eXtreme Programming, Architecture, Design, Agile Development, Methodology, Practice, Systems Develop-

ment, Software Quality, Developer Stories.

Abstract:

Within the ﬁeld of Software Engineering emergence of agile methods has been a hot topic since the late

90s. eXtreme Programming (XP) (Beck, 1999) was one of the ﬁrst agile methods and is one of the most

well-known. However research has pointed to weaknesses in XP regarding supporting development of viable

architectures. To strengthen XP in this regard a new practice: Developer Stories (Jensen et al., 2006) was

introduced last year mainly based on a theoretical argumentation.

This paper reports from extensive experimentation with, and elaboration of the new practice. Results from

this experimentation shows that using Developer Stories increases the likelihood of developing a viable ar-

chitecture through a series of deliberate choices, through creating disciplined and recurring activities that:

1) Facilitate sharing and embodying of knowledge about architectural issues, and 2) heighten visibility of

refactorings for both customers and developers.

1 INTRODUCTION

Agile methods has been a hot topic since the late

90’s (Beck et al., 2001), shifting system develop-

ments focus from processes and tools to individu-

als and interactions, from documentation to working

software, from contract negotiation to customer col-

laboration, from following a plan to responding to

change. eXtreme Programming (Beck, 1999; Beck,

2000; Beck, 2004) was one of the ﬁrst methods within

this paradigm and has become very popular within

both research and industry. However XP has also

been critiqued for not supporting the development of a

viable architecture and hereby jeopardizing the qual-

ity of the developed systems.

What is design and what is architecture? No clear

distinction can be made between the two in general,

and in the case of XP, the two terms are frequently

overlapping - i.e. both in terms of intention and scope.

Architectural issues are dealt with through Enough

Design Up Front combined with constantly designing

and refactoring entailing that the architecture keeps

improving but only on demand. The prevalent princi-

ple presented by XP to guide development of the ar-

chitecture is “Simplicity”, subject to the criteria: “Ap-

propriate for the intended audience”, “Communica-

tive”, “Factored” and “Minimal”.

Does XP deliver a viable architecture? Embrac-

ing the values of XP, and following the practices in a

disciplined manner in accordance with the principles,

will lead to a sufﬁcient and viable architecture (Beck,

2004).

However, discourses in literature and conference

proceedings show that supporting development of a

viable architecture still is a subject in XP. Some ex-

amples of the discourses are:

• The “Metaphor” practice that in the ﬁrst book on

XP (Beck, 1999) explicitly guided architecture,

points to the need of focusing on a shared under-

standing of the system. The practice was found

difﬁcult to operationalize (Fowler, 2001) and was

therefore removed (Beck, 2004), but soon it was

missed (Lippert et al., 2003; West and Solano,

2005) and hints for operationalization was sug-

gested.

• Several have proposed an introduction of some

Njor Jensen R., Platz N. and Tjørnehøj G. (2007).

HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE - Facilitating Knowledge Sharing and Embodiment, and Making Architectural Changes

Visible.

In Proceedings of the Second International Conference on Software and Data Technologies - SE, pages 56-64

DOI: 10.5220/0001338900560064

 SciTePress

kind of requirements management into XP (Eber-

lein and do Prato Leite, 2002; Paetsch et al., 2003)

when quality of the system under development is

a concern.

• Reports of problems trying to integrate large-scale

refactorings into the everyday work of XP projects

(Lippert, 2004). The quote “...aggressive refac-

toring probably will remain the most difﬁcult,

because it requires consistency, energy, and

courage, and no mechanisms in the methodology

reinforce it.” (Cockburn, 2006), brings the deﬁ-

ciency of XP into focus, offering an explanation

of the many attempts at amending XP.

Developer Stories – a new agile practice – was intro-

duced to address the deﬁciency of XP concerning ar-

chitecture and design (Jensen et al., 2006). The new

practice was inspired by the explicit focus on archi-

tecture in more traditional methods, but designed to ﬁt

perfectly in tune with the practices, principles and val-

ues of XP. Developer Stories manage non-functional

and other architectural requirements for systems - in

parallel with the feature-oriented user stories (effec-

tively addressing functional requirements). The pro-

posed practice was argued through a literature-based

analysis (Jensen et al., 2006).

Investigating how Developer Stories works in a

concrete development project is the subject of this pa-

per. Analyzing Developer Stories, we propose a hy-

pothesis: Developer Stories essentially contributes to

the development process by two means: 1) facilitat-

ing sharing and embodiment of knowledge concern-

ing architectural issues, and 2) improving visibility of

architectural changes – thereby giving the customer

more leverage to steer the development process. This

paper presents the results of an experiment with De-

veloper Stories, which sets out to validate this hypoth-

esis, providing evidence that these two means are in

fact present. The experiment is designed as a com-

bination of a ﬁeld- and laboratory experiment, and

evolves around an XP project of 3 iterations with 6 de-

velopers, a coach and an on-site customer. Conclud-

ing upon the experiment, we ﬁnd that our hypothe-

sis is true, and that Developer Stories improve knowl-

edge sharing and heighten visibility by creating reoc-

curring, disciplined activities for exploring and pro-

cessing possible architectural issues.

The remainder of this paper is organized as fol-

lows: Section 2 presents the new practice Developer

Stories in some detail (more arguments can be seen

in (Jensen et al., 2006)). Section 3 presents the ex-

periment settings, data collection and analysis, while

section 4 lists the ﬁndings from the experiment. Re-

sults are summarized in section 5, and then discussed

in section 6. Finally we draw our conclusions in sec-

tion 7, and hint possible future work in section 8.

2 DEVELOPER STORIES

In the following we present in some detail the practice

Developer Stories based on the original description of

Developer Stories (Jensen et al., 2006). For practical

purposes some aspects were clariﬁed before the ex-

periment, but in all important aspects the practice has

remained as the former proposition.

The overall goal of Developer Stories is to pro-

vide the development team with the opportunity and

means to improve the architecture of systems in devel-

opment, accomplishing greater business value, and a

viable architecture.

The Developer Story practice is designed to ﬁt

into the synergetic mesh of XP’s practices. It takes its

place in the symbiotical relationships of the practices,

relating to i.e. pair programming, incremental design,

test-ﬁrst programming and user stories (for clariﬁca-

tion of this see (Jensen et al., 2006)), It is designed

to both support and be supported by the values of XP,

and in general follow the look and feel of XP.

2.1 The Artifact: A Developer Story

Developer Stories as a practice consists of a process –

a number of activities, and artifacts. The artifacts are

the developer stories, deﬁned as such:

The developer stories describe (changes to)

units of developer-visible properties of the

software. In contrast, user stories describe

units of user-visible functionality of the soft-

ware. The physical representation of a devel-

oper story is an index card, which may have

another color than user stories, making it easy

to distinguish them from each other. (Jensen

et al., 2006)

In essence, a developer story is much like a user story

- but where a user story describes features of the sys-

tem and is written by the user, a developer story de-

scribes changes to the system that are often not visible

to the user, but highly visible to the developers – and

is therefore written by the developers.

Figure 1 depicts a developer story from the con-

ducted experiment. The layout of a developer story is

an index card, and the form of the content is not bound

by any formalism. The extent of the content is at the

leisure of the developers. Whether it should contain a

description of the problem, solution, tests, tasks and

estimate, or whether it (as is the case of our example

from the experiment, Figure 1) only needs two lines

of description.

HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE - Facilitating Knowledge Sharing and Embodiment,

and Making Architectural Changes Visible

Figure 1: Example of a developer story.

2.2 The process

The activities that constitute the rest of the practice

is interwoven into the other activities of development

work, especially the discovery of potential devel-

oper stories and implementation of the chosen stories.

However the exploration of the architectural issues,

the writing of the stories and the costumer choosing

which to implement is organized as an autonomous

activity; The Architectural Game.

2.2.1 Acknowledging Architectural Issues

Integrated in the day-to-day activities of an iteration

the developers acknowledge architectural issues that

they experience. They either make a mental note, or

preserve some artifact – a drawing on a ﬂip-chart, a

sticky-note or otherwise. Acknowledgement happens

during pair-programming, shared discussions, lunch-

breaks, etc., and serve as inspiration or reminders at

the following Architectural Game.

2.2.2 The Architectural Game

The Architectural Game (see Figure 2) is a two-hour

meeting that occurs once every iteration just before

or after the weekly planning meeting (Beck, 2004)

(formerly known as the planning game (Beck, 2000))

and may well be performed as a stand-up activity.

The purpose of the game is to explicate and visual-

ize refactoring needs as stories.

As shown in Figure 2 the game is based on expe-

riences (including the notes and artifacts mentioned

above) from the past iteration(s). First the develop-

ers collaboratively explore and elaborate architectural

issues and eventually write developer stories express-

ing refactoring needs. Then they estimate the stories

and may prioritize them. The customer is optimally

present at this part of the Architectural Game as by-

stander. The participants shift rapidly, ﬂuent and im-

perceptibly between activities.

When the developers have expressed the refactor-

ing needs that they have found in terms of developer

Explore and Elaborate

Estimate

Developer stories

Experience from past iteration

Chosen developer stories

Elaborate

Present

Assess business value

Write developer stories

Developer driven, collaborative Customer driven

Choose

Prioritize

Figure 2: The Architectural Game.

stories, the stories are presented to the customer to

choose from. He is responsible for gaining insight in

the developer stories, so that he can assess the busi-

ness value of the stories, based on his detailed busi-

ness knowledge. This might require more elaboration

or further explanations in non-technical terms by the

developers.

2.2.3 Implementing Developer Stories

The chosen developer stories are handled similarly to

the chosen user stories during the following iteration,

e.g. developer stories are implemented and tested

analogously to user stories. New unit tests are added

and existing unit tests modiﬁed. Just like acceptance

ICSOFT 2007 - International Conference on Software and Data Technologies

tests for user stories, acceptance tests for developer

stories are written prior to implementation by the cus-

tomer, though supported by the developers – to up-

hold the double checking principle (Beck, 2004).

3 EXPERIMENT

The overall aim of the performed experiment was to

gain insight into the workings of Developer Stories, to

understand how and why they possibly accommodate

architectural improvement.

3.1 Hypothesis

We regard the architecture of a system, as something

that at any given time can change in several differ-

ent ways. Choosing which changes to implement, is

a matter of assessing which changes (if any) that will

provide the largest increase in the value of the system.

But how do we determine which changes are possible

and which are feasible? And when a set of potential

changes is identiﬁed, who then chooses which to im-

plement? These two questions forms the basis from

which our hypothesis is formed.

Finding Feasible Changes Creating the architecture

of a system can involve many different stakehold-

ers, but it is the developers that have detailed

knowledge of the design and architecture of the

implementation. With this in mind, the different

developers are all potential changers of architec-

ture, and as such the root to uniformity or chaos.

Fowler promotes an unorthodox deﬁnition of ar-

chitecture:

In most successful software projects, the ex-

pert developers working on that project have

a shared understanding of the system design.

This shared understanding is called architec-

ture.(Fowler, 2003)

Following this deﬁnition, and the previously

stated premises, it is necessary to build and main-

tain a shared, uniform understanding of the ex-

isting architecture, in order to identify which

changes to the architecture may feasibly be im-

plemented. Hereby it becomes imperative that any

practice aiming to improve architecture facilitates

knowledge sharing and embodiment.

Choosing Which Changes to Implement While

the developers (may) have an understanding of

the architecture and possible changes, they do

not posses all knowledge required to determine

the change of value of the system entailed by

effectuating a change. The missing knowledge

is possessed by other stakeholders, which in

XP are represented by the on-site customer.

The required knowledge is i.a. the context in

which the system is to be deployed, the context

to which the system is developed, etc. If this

knowledge is to be employed, the customer must

be in a position to execute inﬂuence on which

changes are implemented, and it follows that a

practice aiming to improve the architecture must

provide the customer with visibility of possible

architectural changes.

In short, our hypothesis is that Developer Stories

contribute to the development process with knowl-

edge sharing and embodiment of architectural issues

among the developers, and gives the customer visibil-

ity of the possible architectural changes.

3.2 Experiment Setting

The experiment was a full scale XP-development

project integrated with the Developer Story practice.

It was conducted in a laboratory but striving to share

as many aspects as possible with a ﬁeld experiment

(Galliers and Land, 1987).

The ﬁeld aspects were: 1) The laboratory was

physically set up as a real XP room. 2) 11 out of

13 primary practices, and some secondary practices

were employed in the software development process.

3) The development task was an industry request and

the on-site customer was employed at the requesting

company. 4) There were six developers, which is a

normal size project. 5) We followed three one-week

iterations, which is adequate embody both ordinary as

well as the new practice of XP and thus to study the

effect. 6) The implemented software was real-world:

a rather complex client- and server system applying

new technology used to scan barcodes on parcels in

a freight registration system for a truck ﬂeet operator.

7) After the experiment the IT-system was actually

implemented at the requesting ﬁrm.

The laboratory aspects of the experiment were: 1)

The developers were ﬁfth semester computer science

students with some experience in developing systems,

but unskilled in XP. 2) The researchers played the role

of coach and one on-site customer and the project was

conducted at the university – not in an industry set-

ting.

3.3 Preparing the Experiment

Preparation for the experiment was done through

three activities: Teaching the to-be XP developers XP,

arranging for a laboratory in which to conduct devel-

HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE - Facilitating Knowledge Sharing and Embodiment,

and Making Architectural Changes Visible

Figure 3: Conﬁguration of the development room.

opment, and ﬁnally giving the developers insight into

the product domain.

The developers were taught XP from scratch dur-

ing a 20 hour course over a period of 5 days starting

with and emphasizing the values of XP, later adding

the principles, practices, and other features of XP.

The laboratory was set up as sketched in Figure 3

with one end occupied by three pair programming sta-

tions facing each other and the other end empty except

from the information radiators – blackboards, bulletin

boards (storywall, etc.), and a ﬂip chart. This area also

served as stand-up area. Finally a chair for the on-site

customer was added. Compared to the recommended

setup (Beck, 2004), denoted as “caves and common”

(Cockburn, 2006) there is no private space for the de-

velopers to do solitary work. The need for caves was

met by another room just down the corridor in which

the developers also worked off-project hours.

3.4 Executing the Experiment

The experiment was conducted from mid-October to

end-November. In total, three one-week iterations

where completed. Development time was scattered

throughout this period, concentrating more and more

towards the end. The customer in cooperation with

the researchers wrote the user stories for the project.

The developers were enthusiastic about both XP and

the product. The ﬁrst iteration was a learning iter-

ation with heavy involvement of the coach, but al-

ready in the second iteration the team, to a large de-

gree, worked independently of the coach. The project

was halted after the third iteration as planned only be-

cause the students had to refocus on other parts of

their study. The product was however ready to be im-

plemented and used by the requesting ﬁrm.

3.5 Collecting Data

We used four main sources for collecting data.

• A research log kept daily by the researchers fo-

cused on the themes from the hypothesis of the ex-

periment, including observations and reﬂections

of the ongoing development process.

• A questionnaire, that each developer answered

three times per iteration (start, middle, end), 41

questionnaires in total. The questionnaire pro-

vided evidence on: A) How much Developer Sto-

ries relatively to the other practices contributed to

each developers knowledge of the system, and B)

Whether the systems architecture was perceived

similarly by the developers, and how this percep-

tion evolved.

• The Architectural game was video taped along

with the weekly meetings.

• As the development team employed a source re-

vision control system, the source code at different

revisions constituted the ﬁnal data source.

The researchers were present during all work

hours, taking actively part in the project, which con-

stitutes a source of rich but informal data.

3.6 Analyzing Data

We analyzed data looking for support of the hypothe-

sis (knowledge sharing and embodiment, and visibil-

ity of refactorings).

To provide a historical reference to the remainder

of the analysis, we created a timeline using the log-

book, and the artifacts produced throughout the devel-

opment process (story index cards, ﬂip charts, etc.).

We then reviewed the logbook and video record-

ings, mapping evidence to the main themes of the

hypothesis; interactions between developers (sharing

and embodiment of knowledge), interactions between

developers and the customer (visibility of refactor-

ings), and signs of architectural change (Developer

Stories).

On the ﬂip side of the questionnaire, the develop-

ers depicted their current perception of the architec-

ture. We used these drawings to analyze how the per-

ceptions evolved over time and how they converged

or diverged between developers.

We analyzed the developers own subjective and

relative rating of the contribution to their understand-

ing of the system from Developer Stories, compared

to other practices.

We even analyzed the different builds of the sys-

tem with a code analysis tool (Structure101 (Soft-

ware, 2006)) to see if refactorings due to developer

stories had effect on the actual architecture.

The data analysis was iterative going through sev-

eral of the data sources more than once in the light of

the ﬁndings from the other sources.

ICSOFT 2007 - International Conference on Software and Data Technologies

4 FINDINGS

Presented below is the most signiﬁcant ﬁndings

grouped into four categories – three relating to differ-

ent parts of the Developer Stories process (see Sec-

tions 2.2.1, 2.2.2 and 2.2.3), and one with ﬁndings

applicable to all parts.

4.1 Acknowledging Architectural Issues

We found that knowledge of implementation chal-

lenges, design problems and refactorings was shared

through osmotic communication (Cockburn, 2006),

and the use of the ﬂip chart and blackboards. Typ-

ically a discussion about these architectural issues

would evolve rapidly from involving one pair to en-

gaging one or more persons from the other pairs, and

at some point two or three people would move to the

stand-up area and employ either the blackboard or the

ﬂip chart.

Considering the whole span of development, the

discussions were spread evenly throughout the iter-

ations, and all developers were found to engage ac-

tively in this sharing of knowledge.

The on-site customer, being present in the room,

observed the discussions about architectural issues

when they took place in the stand-up area, and oc-

casionally was able to contribute some knowledge.

There were instances of the customer instigating

a discussion of architectural issues among the devel-

opers, when some functionality was demoed to the

customer, and the customer asked for a change in e.g.

user interface design, functionality or otherwise.

4.2 The Architectural Game

The developers all engaged actively in discussions

about architectural issues experienced in the previous

iteration.

The ﬂip charts and other artifacts that were created

during the iteration leading up to a particular architec-

tural game were used by the developers as reminders

of the experienced architectural issues.

The ﬁrst architectural game was guided by the

coach, and we observed how the developers quickly

and actively engaged in the process, effectively act-

ing as a self-organizing team.

Video recordings from the architectural games

showed a noticeably quick creation of a common and

high level of understanding of the current system dur-

ing the review of the ﬂip chart. The developers ob-

tained this understanding by actively seeking knowl-

edge from each other about aspects of the system that

were currently unclear to them.

Figure 4: Drawings of the system architecture hung on a

wall. Each row corresponds to a developer, time increasing

from left to right.

Frequently we also observed developers feed the

discussion with personal knowledge about i.a. a de-

sign pattern that had not been previously considered.

We observed the developers changing rapidly be-

tween different levels of abstraction – ranging from

overall architectural patterns to implementation de-

tails.

We observed the customer choosing between the

presented developer stories. When he was not im-

mediately able to assess the business value, he chal-

lenged the developers, who where able to present the

developer stories in terms that the customer could

translate into business value.

4.3 Implementing Developer Stories

We found the knowledge of an architectural change

happening due to a developer story spread very

quickly among the developers. The black markings

in Figure 4 shows how the knowledge of a partic-

ular architectural pattern described in a developer

story spreads among the developers. On the 22

November two developers had acknowledged and de-

picted the architectural change. The 28

of Novem-

ber (one working day later), ﬁve developers had ac-

knowledged the change. While the developers ro-

tated in pairs frequently, not all the developers that

acknowledged the architectural change had actually

worked on that particular piece of code.

We found several situations where the customer

was involved in the implementation of developer sto-

ries, just like user stories, either through discussions

or direct questions concerning uncertain matters.

HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE - Facilitating Knowledge Sharing and Embodiment,

and Making Architectural Changes Visible

We analyzed a particular subset of the developed

code in two different versions, and found a signiﬁcant

reduction of coupling and an enhancement of cohe-

sion as an effect of a major refactoring in the third iter-

ation. We see this as a sign of improvement of the ar-

chitecture, according to the deﬁnition of architecture

by the traditional quality criteria (Jensen et al., 2006).

The cause of the refactoring was clearly traceable to

the implementation of a speciﬁc developer story.

4.4 Generally Applicable Findings

From the questionnaires, we found that the develop-

ers themselves subjectively rated the Developer Sto-

ries practice relatively higher than other XP-practices,

as a mean to increase their personal knowledge of the

system, and more so more and more over the itera-

tions.

5 RESULTS

Reﬂecting upon our ﬁndings, the following section

summarizes the results of the experiment with regards

to the hypothesis: “That Developer Stories contribute

to the development process with knowledge sharing

and embodiment of architectural issues among the de-

velopers, and gives the customer visibility of the pos-

sible architectural changes”.

5.1 Knowledge Sharing and

Embodiment

There is widespread evidence that the practice Devel-

oper Stories did heighten the knowledge sharing and

embodiment throughout the whole project by provid-

ing occasion and tools for supporting and informally

documenting the discussions. Even the developers

themselves considered Developer Stories as a prac-

tice that contributed to their knowledge of the system,

to a larger extent than other XP practices.

The knowledge sharing and embodiment pro-

cesses was initiated during the iteration leading up to

the architectural games. The process occurring dur-

ing the iteration was characterized by being problem

oriented, and not necessarily involving all developers.

When the process continued in the architectural game,

focus gradually shifted to become more solution ori-

ented, and being communal, involving all developers.

The rapid shifts in levels of abstraction throughout the

discussion indicates that sharing and embodiment of

knowledge was actually achieved (Guindon, 1990).

When changing the architecture by implement-

ing a developer story, the developers acknowledged

the new architecture faster than otherwise expected.

This indicates that the developers effectively embod-

ied knowledge about architectural development that

occurred due to developer stories.

The Architectural Game resulted in a shared and

deep knowledge of the constituent parts of the system.

Moreover, the developers perception of the architec-

ture was uniform. Keeping the deﬁnition of architec-

ture as a common understanding of the most impor-

tant elements in mind, this means that the developers

where in fact able to communicate about the same ar-

chitecture, enabling them to make a uniform, disci-

plined and deliberate change of the architecture.

5.2 Visibility of Refactorings

The customer participated, through observation, in-

stigation, control and sparring in all three parts of the

Developer Stories process. This working pattern gave

the customer an inﬂuence on both choice and imple-

mentation of developer stories equal to that of user

stories, and some insight into the creation process.

The participation provided the customer with the

insight needed for choosing what to include and to ex-

clude (e.g. to avoid gold-plating) in the different iter-

ations. This way the visibility combined with the cus-

tomers knowledge of the systems context enhanced

the architecture of the system, as decisions can be

fully informed.

The act of choosing which developer stories to im-

plement gave the customer a very tangible lever with

which to control the direction of development in ar-

chitectural matters.

As a positive side effect, the developers gained

knowledge of the rationale on which the choice of de-

veloper stories was made, rendering them more em-

pathetic towards the choices.

5.3 Effect of Developer Stories

When implementing developer stories, the architec-

ture was evidently improved, but while we do con-

clude that the improvement in architectural quality we

found, was due to implementing a developer story, we

are not able to state for certain that the same refactor-

ing had not happened in some other course of devel-

opment.

However, based on this ﬁnding and on our gen-

eral belief that communication raises the possibility

of informed and thus wiser decisions, we do specu-

late that implementing the Developer Stories practice

is likely to heighten quality of the architecture early

in a development process by providing occasions for

disciplined elaboration of the architecture.

ICSOFT 2007 - International Conference on Software and Data Technologies

6 DISCUSSION

Our results from the experiment showed that the sug-

gested practice Developer Stories had effect on how

developers worked with architectural issues of the

system and also on the architecture of the system it-

self.

We found that developer stories helped developer

and customer to focus on needed non-functional or

other architectural requirements in a consistent (reoc-

curring once every iteration), disciplined and struc-

tured (in terms of developer stories) manner balanced

with the rest of the practices in XP. Based on this we

argue that Developer Stories can strengthen XP, effec-

tively accommodating the critique of the aggressive

refactoring (Cockburn, 2006) and providing a more

disciplined approach to design activities as suggested

(Fowler, 2004) while not jeopardizing the symbioses

of the existing practices of XP.

From the suggested practice follows a high degree

of visibility of needed refactoring tasks, of their value

for the customer, of their cost (estimated) and of the

customers eventual choice of stories. This visibil-

ity secures highly informed decisions on functional-

ity and architecture and is thus likely to add greatly to

the overall value of the system. Being continuous it

could play some role of bounded requirements man-

agement, since all stories are known to the decision

maker and he in turn is actively consulting and con-

sulted by the developers.

We also found that Developer Stories affected

knowledge sharing amongst the developer group and

with the customer as well, due to his presence through

the Architectural Game. Building and maintaining a

uniform perception of the architecture is a prerequi-

site for making meaningful and consistent architec-

tural changes. We also think this practice through

supporting building of shared abstract common un-

derstanding of the system can add what was lost when

the Metaphor practice was excluded from XP.

We can however not conclude anything regarding

the actual quality of the architecture according to the

classic criteria (Jensen et al., 2006). Securing quality

is not guaranteed by following the practice as such,

but the practice makes it possible and maybe even

more likely.

A consideration regarding the experiment setup is,

that the on-site customer was technically knowledge-

able. As such, we do acknowledge that communicat-

ing developer stories in terms that the customer may

translate to business value is a major challenge for the

involved parties. Considering the course of events

during the experiment, we do however believe that

this communication can be mastered by both devel-

opers and customer after a period of practice.

It should be recognized that a control group might

have been employed to compare the performance of

Developer Stories. Such a control group was not how-

ever within the scope of the research project. We do

still consider the results of the experiment valid, due

to the fact that we do only conclude upon the presence

of knowledge sharing and embodiment, and visibility,

not upon general positive or negative affects on the ar-

chitecture when using Developer Stories.

7 CONCLUSION

We have experimented with integrating the practice

of Developer Stories into XP to investigate the ef-

fect. The experiment was a full-scale XP develop-

ment project of 3 iterations, 6 developers, one on-site

customer and a coach, working on at real industry re-

quest. The product is now being implemented in the

requesting ﬁrm. From the experiment we found that

the practice Developer Stories contributes to the de-

velopment process by: 1) Heightening visibility of

refactorings for both customers and Developers, 2) fa-

cilitating sharing and embodying of knowledge about

architectural issues and 3) creating occasions for a

disciplined elaboration of the architecture. We spec-

ulate that by this contribution, Developer Stories give

development teams better means for achieving viable

architectures in developed systems.

8 FUTURE WORK

Investigating how Developer Stories may be used in

agile development methodologies other than XP is an

open question, and subject to ongoing work.

Gaining further insight into the effect of De-

veloper Stories may be carried out by using De-

veloper Stories in real-world projects. Experiences

from any such activity would be very interesting,

and may well be reported communally on

www.

developerstories.org

REFERENCES

Beck, K. (1999). Embracing change with extreme program-

ming. Computer, 32(10):70–77.

Beck, K. (2000). Extreme Programming Explained: Em-

brace Change. Addison-Wesley.

Beck, K. (2004). Extreme Programming Explained: Em-

brace Change. Addison-Wesley, 2 edition.

HOW “DEVELOPER STORIES” IMPROVES ARCHITECTURE - Facilitating Knowledge Sharing and Embodiment,

and Making Architectural Changes Visible

Beck, K., Beedle, M., van Bennekum, A., Cockburn, A.,

Cunningham, W., Fowler, M., Grenning, J., High-

smith, J., Hunt, A., Jeffries, R., Kern, J., Marick, B.,

Martin, R. C., Mellor, S., Schwaber, K., Sutherland,

J., and Thomas, D. (2001). Manifesto for agile soft-

ware development.

http://agilemanifesto.org

Cockburn, A. (2006). Agile Software Development, The Co-

operative Game. Pearson Education, Inc.

Eberlein, A. and do Prato Leite, J. C. S. (2002). Ag-

ile requirements deﬁnition: A view from require-

ments engineering. In TCRE’02.

http://www.enel.

ucalgary.ca/tcre02/

Fowler, M. (2001). Design: Reducing coupling. IEEE Soft-

ware, 18(4):102–104.

Fowler, M. (2003). Who needs an architect? IEEE Soft-

ware, 20(5):11–13.

Fowler, M. (2004). Is design dead.

http://

martinfowler.com/articles/designDead.html

Galliers, R. D. and Land, F. F. (1987). Viewpoint - choosing

appropriate information systems research methodolo-

gies. Communications of the ACM, 30(11):900–902.

Guindon, R. (1990). Designing the design process: Ex-

ploiting opportunistic thoughts. Human-Computer In-

teraction, 5:305–344.

Jensen, R. N., Møller, T., S

onder, P., and Tjørnehøj, G.

(2006). Architecture and Design in eXtreme Program-

ming; introducing “Developer Stories”. In Lecture

Notes in Computer Science : Extreme Programming

and Agile Processes in Software Engineering, pages

133–142. Springer Berlin / Heidelberg.

Lippert, M. (2004). Towards a proper integration of large

refactorings in agile software development. In Lecture

Notes in Computer Science, volume 3092, pages 113

– 122. Springer-Verlag.

Lippert, M., Axel, Schmolitzky, and Z

ullighoven, H.

(2003). Metaphor design spaces. volume 2675 of

Lecture Notes In Computer Science, pages 33–40.

Springer-Verlag.

Paetsch, F., Eberlein, A., and Maurer, F. (2003). Re-

quirements engineering and agile software develop-

ment. In Twelfth International Workshop on Enabling

Technologies: Infrastructure for Collaborative Enter-

prises, page 308.

Software, H. (accessed 29. december 2006). Struc-

ture101.

http://www.headwaysoftware.com/

products/structure101/

West, D. D. and Solano, M. (2005). Metaphors be with you!

In Agile2005.

ICSOFT 2007 - International Conference on Software and Data Technologies