scispace - formally typeset
Search or ask a question

Showing papers on "User story published in 2007"


Proceedings ArticleDOI
13 Jun 2007
TL;DR: This work reports on user studies to measure user satisfaction with resource borrowing and with different clock frequencies in desktop computing, the development and evaluation of user interfaces to integrate user feedback into scheduling and clock frequency decisions in this context, and results in predicting user action and system response in a remote display system.
Abstract: Experimental computer systems research typically ignores the end-user, modeling him, if at all, in overly simple ways. We argue that this (1) results in inadequate performance evaluation of the systems, and (2) ignores opportunities. We summarize our experiences with (a) directly evaluating user satisfaction and (b) incorporating user feedback in different areas of client/server computing, and use our experiences to motivate principles for that domain. Specifically, we report on user studies to measure user satisfaction with resource borrowing and with different clock frequencies in desktop computing, the development and evaluation of user interfaces to integrate user feedback into scheduling and clock frequency decisions in this context, and results in predicting user action and system response in a remote display system. We also present initial results on extending our work to user control of scheduling and mapping of virtual machines in a virtualization-based distributed computing environment. We then generalize (a) and (b) as recommendations for incorporating the user into experimental computer systems research.

40 citations


Proceedings ArticleDOI
H. Williams1, A. Ferguson1
13 Aug 2007
TL;DR: This work is successfully demonstrating how two UCD teammates on the agile team can aid in upfront and continual user input.
Abstract: In the agile and user-centered design (UCD) communities it is often believed that agile's quick development cycles do not allow time to fully understand our user's needs. In our experience it is just the opposite: agile and UCD methods are not at odds with each other. As more development teams using UCD are finding, the iterative approach to agile is a natural fit for UCD. Though we have day to day challenges, we are successfully demonstrating how two UCD teammates on the agile team can aid in upfront and continual user input.

40 citations


Proceedings ArticleDOI
19 Oct 2007
TL;DR: If the user is given advice, the number of queries she needs to try before finding the product of highest utility is greatly reduced and an advisor that confines its advice to queries that the user model predicts are likely to be tried next will give shorter advice than one whose advice is unconstrained by the user models.
Abstract: Consider a conversational product recommender system in which a user repeatedly edits and resubmits a query until she finds a product that she wants. We show how an advisor can: observe the user's actions; infer constraints on the user's utility function and add them to a user model; use the constraints to deduce which queries the user is likely to try next; and advise the user to avoid those that are unsatisfiable. We call this information recommendation. We give a detailed formulation of information recommendation for the case of products that are described by a set of Boolean features. Our experimental results show that if the user is given advice, the number of queries she needs to try before finding the product of highest utility is greatly reduced. We also show that an advisor that confines its advice to queries that the user model predicts are likely to be tried next will give shorter advice than one whose advice is unconstrained by the user model.

29 citations


Journal ArticleDOI
TL;DR: The aim is to create an understanding about categorization practices in design through a case study about the virtual community, Habbo Hotel, and a qualitative analysis highlighted not only the meaning of the "average user," but also the work that both the developer and the category contribute to this meaning.
Abstract: The "user" is an ambiguous concept in human-computer interaction and information systems. Analyses of users as social actors, participants, or configured users delineate approaches to studying design-use relationships. Here, a developer's reference to a figure of speech, termed the "average user," is contrasted with design guidelines. The aim is to create an understanding about categorization practices in design through a case study about the virtual community, Habbo Hotel. A qualitative analysis highlighted not only the meaning of the "average user," but also the work that both the developer and the category contribute to this meaning. The average user a) represents the unknown, b) influences the boundaries of the target user groups, c) legitimizes the designer to disregard marginal user feedback, and d) keeps the design space open, thus allowing for creativity. The analysis shows how design and use are intertwined and highlights the developers' role in governing different users' interests.

24 citations


Book ChapterDOI
18 Jun 2007
TL;DR: This descriptive case study is about the dynamics of a software engineering team using executable acceptance test-driven development in a real world project and the observed consensus among multiple stakeholders speaks of the effectiveness of the practice in the given context.
Abstract: This descriptive case study is about the dynamics of a software engineering team using executable acceptance test-driven development in a real world project. The experiences of a customer, a developer, and a tester were discussed. The observed consensus among multiple stakeholders speaks of the effectiveness of the practice in the given context.

22 citations


Book ChapterDOI
18 Jun 2007
TL;DR: This experience report is about how one project in Norway made an agile approach to specifying software requirements for a new intranet, spending a few weeks specifying a prioritized list of high-level requirements.
Abstract: This experience report is about how one project in Norway made an agile approach to specifying software requirements for a new intranet. Rather than spending months on trying to detail all requirements and aspects of the solution, the team spent a few weeks specifying a prioritized list of high-level requirements. Further details will emerge by face-to-face communication through the iterations of the project quickly turning in to valuable working software for the customer.

20 citations


01 Jan 2007
TL;DR: The goal of the paper is to identify estimation issues in the most known and adopted agile methodologies, looking at possible improvements at the organiseational level.
Abstract: From the mid ‘90s on, a number of Agile Methodologies have been proposed, most of them based on the basic values and principles summarised in the 2001 “Agile Manifesto”. These agile methodologies were aimed at small teams with severe project constraints (i.e. small project teams in the same location, the customer as a member of the project team, informal communication, test-driven approach, etc.). Compared to more traditional project methodologies, Agile (or Lightweight) Methodologies are more detailed on Construction and Testing practices, but much less specific about other topics, such as Estimation. Currently, in most Agile Methodologies the experience of the team represents the basis for estimating from the high-level requirements. The application of a Functional Size Measurement Method (FSMM) for estimation purposes raises a number of technical problems in Agile projects (i.e. unstable requirements, iterative SLC, non-functional requirements). A candidate solution is to combine an early sizing method for an agile project with a full FSMM method to be applied later in the SLC, when User Stories (the way XP labels high-level functional requirements) become available and are more stable. The goal of the paper is to identify estimation issues in the most known and adopted agile methodologies, looking at possible improvements at the organiseational level.

20 citations


Proceedings ArticleDOI
28 Apr 2007
TL;DR: This special interest group meeting has three purposes: to bring the results of a recent week-long "Dagstuhl" meeting on end-user software engineering to interested researchers at CHI; to incorporate attendees' ideas and feedback into an emerging survey of the state of this interesting new subarea.
Abstract: Recently, researchers have been working to bring the benefits of rigorous software engineering methodologies to end users who find themselves in programming situations, to try to make their software more reliable. End users create software whenever they write, for instance, educational simulations, spreadsheets, or dynamic e-business web applications. Unfortunately, errors are pervasive in end-user software, and the resulting impact is sometimes enormous. This special interest group meeting has three purposes: to bring the results of a recent (February 2007) week-long "Dagstuhl" meeting on end-user software engineering to interested researchers at CHI; to incorporate attendees' ideas and feedback into an emerging survey of the state of this interesting new subarea; and generally to bring together the community of researchers who are addressing this topic, with the companies that are creating end-user programming tools.

19 citations


Proceedings ArticleDOI
01 Oct 2007
TL;DR: It is concluded that the inclusion of Use Cases in Agile Requirements could benefit Agile teams, and the presence of the Use Cases helped subjects to ask better questions to the On-Site Customer.
Abstract: Agile teams commonly use User Stories, conversations with On-Site Customers, and Test Cases to gather requirements. Some Agile teams like to add other artifacts, such as Use Cases to provide more detail to the Agile Requirements. This paper presents the results of a controlled experiment aimed to learn whether Use Cases could help Agile Requirements, and, indirectly, to find if Agile Requirements techniques are sufficient. In the study, subjects were given requirements for three maintenance tasks as Use Cases, or Agile Requirements, or both. We found that subjects using Use Cases spent less time understanding requirements in comparison to subjects not using Use Cases. In addition, the presence of the Use Cases helped subjects to ask better questions to the On-Site Customer. However, we could not determine if subjects using Use Cases understood the requirements better. We conclude that the inclusion of Use Cases in Agile Requirements could benefit Agile teams.

15 citations


Proceedings ArticleDOI
04 Nov 2007
TL;DR: By understanding the user as a contextual feature in developers' group work the authors are able to draw attention to issues in the use of Extreme Programming for software product development.
Abstract: This paper examines how software developers discuss users and how such discussions are intrinsic to the negotiation and settling of technical decisions in the development and testing of a software product. Using ethnographic data, we show how the user features in conversations, not as a 'topic' but as 'context' to technical work. By understanding the user as a contextual feature in developers' group work we are able to draw attention to issues in the use of Extreme Programming for software product development. Extreme Programming is a participatory design method, but software product development involves envisioning and designing for future customers.

14 citations


Book ChapterDOI
22 Jul 2007
TL;DR: The results indicate that the proposed approach has possibility to help designer and multi-disciplinary team to consider user experience for user centered design.
Abstract: The purpose of this study is to develop an approach to artifacts design based on information technology. To make interactive system easy to use, user centered design approach is utilized by many systems. For user centered design, it is important to consider total user experience. But it is not easy to consider total user experience because user experience is including many aspects. To approach total user experience, the author proposes the method of designing for user experience that consist of "User viewpoint", "Environment viewpoint" and "Lifecycle viewpoint". "User viewpoint" is including several user groups from universal design viewpoint, several user characters and several user emotions. "Environment viewpoint" is including hardware product, software, application, space, people who is communicating. "Lifecycle viewpoint" is including pre sales, after sales, support, upgrade, setup product and application. To help this design approach, user experience design tool named "UED (User Experience Design) Studio" was proposed. Based on proposed three approaches, design tools were developed such as "The definition tool", "The evaluation tool" and "The visualization tool" for user experience design. To define user experience situation easily, "The definition tool" helps designer such selecting user group, selecting environment and input user tasks based on life cycle state. "The evaluation tool" is to evaluate defined user experience easily. And "The visualization tool" is to show the result of evaluation by 3 D graphics easy to understand complicated information. To evaluate proposed tools, experiment to make prototype was conducted and the results indicate that the proposed approach has possibility to help designer and multi-disciplinary team to consider user experience for user centered design.


Dissertation
01 Jan 2007
TL;DR: The aim of this research is to generate effective, flexible and responsive explanations, in educational software systems, through developing better explanation facilities than exist in currently available ITS software, by advancing research into dialogue planning and user modelling.
Abstract: ITSs (Intelligent Tutoring Systems) provide a way of addressing some of the issues that the more traditional CAI (Computer Aided Instruction) systems do not address - the individual learning needs and individual learning abilities and levels of users - so that the user is in control of their learning experience. An ITS needs to be able to provide an explanation, for a real world situation, that successfully meets the needs of the user. To ensure relevant explanation content requires the ITS be based on sound planning principles and tutoring knowledge as well as knowledge of the domain and the user. To ensure a coherent explanation structure requires that the tutoring knowledge be applied with full recognition of the knowledge of the domain and the user. For a model of the user's knowledge to be effective, the system should be able to use it to enhance the flexibility and responsiveness of explanations generated. A user model should guide the generation of explanations so they are pitched at the correct level of the user's existing knowledge; models should be able to actively support the needs of the user so that the user's efforts in seeking out information are minimised. The aim of this research is to generate effective, flexible and responsive explanations, in educational software systems, through developing better explanation facilities than exist in currently available ITS software. In achieving this aim, I am advancing research into dialogue planning and user modelling. The explanation facilities described meet the requirements of an explanation that is tailored to the user's needs, a sound theory from which particular explanations are constructed, and a user model that can accurately represent the behaviour and beliefs of the user. My research contributions include explicitly and formally representing discourse planning / reasoning, from both the user's view and the tutor's view so that they can be clearly understood and represented in the ITS. More recent planners have adopted approaches that can be characterised as using adaptations of the classical planning approach, with informally specified planning algorithms and planning languages. Without clear, explicit and full descriptions of actions and the planning algorithm we can not be certain of the plans that such planners produce. I adopt a theoretically rigorous approach based on classical planning theory - the actions available to the planner, the planning language and algorithm should be explicitly represented to ensure that plans are complete and consistent. Classical regression planning uses dynamic planning thus enabling the system to be flexible in a variety of situations and providing the responsiveness required for an ITS. I take a theoretically rigorous approach in constructing a well specified model of discourse, building upon existing research in the area. I present a tutoring module that is able to find a way to motivate the user to take a recommended action, by relating the action to the user's goals, and that is able to reason about the text structure to generate an effective explanation - putting together several clauses of text whilst maintaining coherency. As part of developing such constructs for motivating, enabling and recommending, as well as constructs for structuring text, I use a pedagogic model based on the principled approach of (i) advising the user to take an action (ii) motivating the user to want to take the action and (iii) ensuring the user knows how to do the action. I take a clear and realistic approach to user modelling, making explicit models of the user's behaviour and beliefs. I adopt a theoretically rigorous approach, formally distinguishing between the user's reasoning and their actions, so they can be focused on separately. Formally making this distinction, more easily enables models of the user's reasoning to be tailored to the individual user. To enable the tutor to consider the full impact on the user, of the information to be delivered to the user, I use different plan spaces. I explicitly identify the different perspectives of the user and the tutor so that they can be focused on separately to generate an explanation that is tailored to the user. In my approach, reasoning about the user's skills, rules and knowledge is independent from reasoning about those of the tutor.

Proceedings ArticleDOI
B. Hanks1
13 Aug 2007
TL;DR: A three year journey toward agility in a software engineering course describes a highly agile approach based on short iterations and user stories that was more successful, as every project team delivered working software to their clients.
Abstract: This experience report describes a three year journey toward agility in a software engineering course. Students in the course work in small project teams to develop an application for a real client using the service-learning model. In the first year, a formal plan-driven approach was used, and only two of four projects were completed successfully. A more agile approach was taken the second year, but there were still failing projects. In the third year a highly agile approach based on short iterations and user stories was used. This was more successful, as every project team delivered working software to their clients. This paper also discusses some of the challenges of managing and evaluating student work when using agile methods.

Book ChapterDOI
18 Jun 2007
TL;DR: This paper shows how agile practices have been used at the Poste Italiane for building a monitoring system of its complex IT infrastructure, called Datamart, which is able to process data coming from 100,000 distributed computers, enabling and improving their centralized control.
Abstract: In this paper we show how agile practices have been used at the Poste Italiane for building a monitoring system of its complex IT infrastructure The system, called Datamart, is built upon the existing monitoring infrastructure A testing framework has been developed for performing assertion checking either on existing legacy modules or on the new functionalities This framework is currently used, and is able to process data coming from 100,000 distributed computers, enabling and improving their centralized control

Posted Content
01 Nov 2007
TL;DR: The lazy user theory of solution selection is presented, two case examples are presented, and the implications of lazy user behavior on user attachment to mobile services and devices, and to planning and execution of mobile services are discussed.
Abstract: In this position paper we suggest that a user will most often choose the solution (device) that will fulfill her (information) needs with the least effort. We call this “lazy user behavior”. We suggest that the principle components responsible for solution selection are the user need and the user state. User need is the user’s detailed (information) need (urgency, type, depth, etc.) and user state is the situation, in which the user is at the moment of the need (location, time, etc.); the user state limits the set of available solutions (devices) to fulfill the user need. The context of this paper is the use of mobile devices and mobile services. We present the lazy user theory of solution selection, two case examples, and discuss the implications of lazy user behavior on user attachment to mobile services and devices, and to planning and execution of mobile services.

Proceedings Article
01 Jan 2007
TL;DR: A new project management tool to measure and ensure common understanding of development artifacts is presented, based on Peirce's theory of semiotics and Mayer’s theory of learning.
Abstract: The success of information system development projects is critically dependent on arriving at a shared understanding of the desired outcome by all project stakeholders. To communicate such understanding among stakeholders, development artifacts such as design specifications, prototypes, and user stories are created. This paper presents a new project management tool to measure and ensure common understanding of such development artifacts. The method is based on Peirce’s theory of semiotics and Mayer’s theory of learning. The application of the method is demonstrated using a brief example.


Book ChapterDOI
18 Jun 2007
TL;DR: Simulation retrospectives inside the Joining the Dots 3 event have confirmed that BT may have succeeded in generating large scale buy-in to using agile practices across thousands of people in their delivery organization.
Abstract: While British Telecom (BT) has been progressing the adoption of agile practices across teams for the last two years, the overall organizational transformation has been slow to emerge and a catalyst was needed. In November 2006, BT began running a series of one hundred person, one and a half day events called Joining the Dots 3, aimed at promoting the use of agile throughout the IT organization. The event's practical approach of embedding learning through the use of videos and activities on agile planning, user stories, customer collaboration and iterative delivery into a large scale end-to-end simulation has proven to be both fun and an excellent learning tool. Simulation retrospectives inside the event echo the learning points and feedback forms have confirmed that BT may have succeeded in generating large scale buy-in to using agile practices across thousands of people in their delivery organization.

Book ChapterDOI
18 Jun 2007
TL;DR: This experience report talks about applying agile tools, namely, user stories and acceptance tests, to resolve problems in offshore software development and shows the importance of discussing technical project limitations.
Abstract: This experience report talks about applying agile tools, namely, user stories and acceptance tests, to resolve problems in offshore software development. These tools help to formulate and to better understand results and goals of projects, and to avoid miscommunications about expectations. The report shows the importance of discussing technical project limitations.

Book ChapterDOI
18 Jun 2007
TL;DR: This paper describes a project where stories were used on a much broader scale as part of a strategic planning exercise to identify a long-term development roadmap for a new system.
Abstract: In agile development stories are typically used to define small, independent pieces of functionality that have value for the customer. They are most often used to define requirements for future development. This paper describes a project where stories were used on a much broader scale as part of a strategic planning exercise to identify a long-term development roadmap for a new system. Stories were used not only to define what needed to be built but also to document existing functionality and gaps with current systems. This resulted in the generation of a large number of stories, which created challenges with managing and keeping the stories up to date as the project proceeded.

01 Jan 2007
TL;DR: Examining the core requirements management needs that are common to software development of all flavors and describing a tool concept designed to bring lightweight requirements management to the agile (predominantly XP) context are examined.
Abstract: The majority of commercial requirements management tools tend to be costly, document-driven and used by large organizations undertaking traditional forms of software development. While they are not immediately in the spirit of the agile philosophy, which advocates live dialogue over documentation and encourages small teams of developers to do the simplest thing possible to satisfy a requirement, there are some fundamental practices supported by these tools that play a role in more agile forms of software development. This paper examines the core requirements management needs that are common to software development of all flavors and describes a tool concept designed to bring lightweight requirements management to the agile (predominantly XP) context. This work is based on experiences in using agile development practices within ibm.com, and on the transition from manually handling paper-based story cards to the use of first generation story management tools. The paper discusses early feedback on the concept from practitioners.

Proceedings ArticleDOI
20 May 2007
TL;DR: A new user-extensible model for semi-structured data items is developed, enabling end-user programmers to create, share, and apply topes, enabling these users to quickly implement data validation and reformatting functionality.
Abstract: Many end user programming tools such as spreadsheets and databases offer poor support for representing data at a level of abstraction that is intuitive to users. For example, users must work with "strings" rather than person names, phone numbers, or street addresses. As a result, validating and manipulating data is difficult. This thesis develops a new user-extensible model for semi-structured data items. Each "tope" within this model defines how to recognize a kind of data item based on format and context, and how to transform that kind of item among valid formats. To show the usefulness of this model, we provide an environment to help end-user programmers to create, share, and apply topes, enabling these users to quickly implement data validation and reformatting functionality.

13 Feb 2007
TL;DR: In this article, the authors argue that eXtreme Programming (XP) currently places insufficient emphasis on problem understanding and propose an approach that offers additional front end analysis based on Soft Systems Methodology (SSM).
Abstract: Software development can be treated as a form of 'problem solving'. The two main activities are then (i) understanding the problem, by analysing the situation to determine relevant requirements; and (ii) solving the problem, by implementing software that takes account of those requirements. This paper argues that eXtreme Programming (XP) currently places insufficient emphasis on problem understanding and proposes an approach that offers additional front end analysis based on Soft Systems Methodology (SSM). The models of SSM are linked to XP through user stories. The first part of the paper outlines the process involved. This is followed by details of an initial investigation of the proposal, involving experimental group projects with undergraduate computing students. The results highlight some of the strengths and weaknesses of the approach, indicating directions for future research.

Book ChapterDOI
22 Jul 2007
TL;DR: In this article, a new practice, developer stories, was introduced to strengthen eXtreme Programming (XP) in this regard, mainly based on a theoretical argumentation, which has been a hot topic since the late 90s.
Abstract: Within the field of Software Engineering emergence of agile methods has been a hot topic since the late 90s. eXtreme Programming (XP) ([1]) was one of the first 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 ([2]) was introduced in 2006 - mainly based on a theoretical argumentation.

Book
01 Jan 2007
TL;DR: Usability in Agile Software Development: Extending the Interaction Design Process with Personas Approach and Defining an Integrated Agile Governance for Large Agile software Development Environments.
Abstract: Managing Agile Processes.- Comparing Decision Making in Agile and Non-agile Software Organizations.- Up-Front Interaction Design in Agile Development.- British Telecom Experience Report: Agile Intervention - BT's Joining the Dots Events for Organizational Change.- Agile Software Development Meets Corporate Deployment Procedures: Stretching the Agile Envelope.- Extending Agile Methodologies.- Supporting Agile Reuse Through Extreme Harvesting.- Using Horizontal Displays for Distributed and Collocated Agile Planning.- Applying Agile to Large Projects: New Agile Software Development Practices for Large Projects.- Teaching and Introducing Agile Methodologies.- Job Satisfaction and Motivation in a Large Agile Team.- Motivation and Cohesion in Agile Teams.- How to Build Support for Distributed Pair Programming.- Methods and Tools.- A Metamodel for Modeling and Measuring Scrum Development Process.- Tracking the Evolution of Object-Oriented Quality Metrics on Agile Projects.- FitClipse: A Fit-Based Eclipse Plug-In for Executable Acceptance Test Driven Development.- EzUnit: A Framework for Associating Failed Unit Tests with Potential Programming Errors.- Empirical Studies.- Does XP Deliver Quality and Maintainable Code?.- Inspecting Automated Test Code: A Preliminary Study.- A Non-invasive Method for the Conformance Assessment of Pair Programming Practices Based on Hierarchical Hidden Markov Models.- Predicting Software Defect Density: A Case Study on Automated Static Code Analysis.- Empirical Evidence Principle and Joint Engagement Practice to Introduce XP.- Methodology Issue.- Power of Recognition: A Conceptual Framework for Agile Capstone Project in Academic Environment.- Agile Commitments: Enhancing Business Risk Management in Agile Development Projects.- Usability in Agile Software Development: Extending the Interaction Design Process with Personas Approach.- Defining an Integrated Agile Governance for Large Agile Software Development Environments.- Ph.D. Symposium.- Enhancing Creativity in Agile Software Teams.- Investigating Adoption of Agile Software Development Methodologies in Organisations.- Agile Software Assurance.- Posters.- User Stories and Acceptance Tests as Negotiation Tools in Offshore Software Development.- A Case Study of the Implementation of Agile Methods in a Bioinformatics Project.- Adapting Test-Driven Development for Innovative Software Development Project.- Learning Agile Methods in Practice: Advanced Educational Aspects of the Varese XP-UG Experience.- Experience Reports.- Overcoming Brooks' Law.- Project Bid on Iteration Basis.- Making the Whole Product Agile - A Product Owners Perspective.- Financial Organization Transformation Strategy.- An Agile Approach to Requirement Specification.- The Application of User Stories for Strategic Planning.- Introducing Agile Methods into a Project Organisation.- Agile Development Meets Strategic Design in the Enterprise.- An Agile Approach for Integration of an Open Source Health Information System.- Agile Practices in a Large Organization: The Experience of Poste Italiane.- Multi-tasking Agile Projects: The Focal Point.- Extreme Programming Security Practices.- Multi-tasking Agile Projects: The Pressure Tank.- The Creation of a Distributed Agile Team.- Distributed Scrum in Research Project Management.- Multiple Perspectives on Executable Acceptance Test-Driven Development.- Test Driving the Wrong Car.- Epistemological Justification of Test Driven Development in Agile Processes.- Research Ideas.- How Does Readiness for Agile Development Relate to Team Climate and Individual Personality Attributes?.- Communication Flow in Open Source Projects: An Analysis of Developers' Mailing Lists.- Panels.- Community Reflections.- To Certify or Not to Certify.- Learning More About "Software Best Practices".

Book ChapterDOI
22 Jul 2007
TL;DR: The role of the engineers in the early phases of the user centered process, and the learnings and challenges that come from this approach are described.
Abstract: Chinese culture and consumer patterns are dramatically different from those in the US and Europe. That greatly impacts the types of products that are relevant to the Chinese market, the product development life cycle and methods by which these products are defined and developed for information and communication technologies (ICT). To address those unique differences, the User Centered Design (UCD) research team at Intel China has developed and refined techniques for involving engineering staff in the early stages of product design, namely user research and experience design. This early involvement has many advantages and improves the overall effectiveness of the product development team. This article describes the role of the engineers in the early phases of the user centered process, and the learnings and challenges that come from this approach. Real-world case studies are used to illustrate the methodologies.

Proceedings ArticleDOI
13 Aug 2007
TL;DR: It is intended to highlight some of the pitfalls that can result from using technical stories, and demonstrate clearly why sticking to user stories has its benefits.
Abstract: Across the agile community there has been a lot of discussion regarding the use of technical stories. While the community seems split into two camps of for and against, the majority of extreme programmers favour to define the system using only the traditional customer focused user stories. In some cases the technical story arguments are academic, but our experience report demonstrates clearly why sticking to user stories has its benefits. Our experience using Scrum and XP has been that allowing technical stories into the process can de-rail the ability to deliver constant, measurable business value per iteration, as well as inhibit the planning process. Once technical stories are allowed, the customer and business can be alienated very quickly, especially when they have no engineering background. Furthermore, when problems occur and the technical stories begin to slip, the customer can be left in a very difficult position, not knowing how to re- prioritise or direct the process. It is therefore our intention to highlight some of the pitfalls that can result from using technical stories.


Journal Article
Zhao Ming1
TL;DR: A simple, but realistic mathematic method to estimate the productivity and iteration periods of XP project can be useful in estimation of development cost and effort.
Abstract: The development period of a Extreme Programming(XP) project depends on the productivity of development team.The productivity can be described by probability of which all user stories are achieved successfully in each iteration phase.In this paper,we presented a simple,but realistic mathematic method to estimate the productivity and iteration periods of XP project.The approach can be useful in estimation of development cost and effort.The approach was verified valid with a set of simulation data.