scispace - formally typeset
Search or ask a question

Showing papers on "User story published in 2010"


Dissertation
15 Oct 2010
TL;DR: The thesis describes the importance and characteristics of agile methodologies for software development, focusing on the currently most widely used methodology - Scrum, and presents the most widely spread user stories estimation techniques.
Abstract: The thesis describes the importance and characteristics of agile methodologies for software development, focusing on the currently most widely used methodology - Scrum. In addition to basic features and the presentation of the Scrum development process, the paper describes the specification of user requirements through user stories and their use in the above-mentioned methodology. It also presents the most widely spread user stories estimation techniques and gives a detailed examination of the technique called Planning poker. The paper concludes with a review of tools that support project management tasks and their comparison with the help of a decision model and the program DEXi.

828 citations


Book ChapterDOI
01 Jan 2010
TL;DR: A user experience-centered development process is presented, allowing readers to understand when to use what kind of user experience evaluation methods to achieve a positive user experience.
Abstract: Based on an overview on currently used definitions of user experience in human–computer interaction and major concepts from game development like immersion, flow, and playability, this overview describes a set of evaluation methods and their applicability in the various game development phases. Summarizing the contributions in this book, a user experience-centered development process is presented, allowing readers to understand when to use what kind of user experience evaluation methods to achieve a positive user experience.

73 citations


Journal ArticleDOI
TL;DR: The results offer insights into the impact of user participation on generating higher levels of developer and user satisfaction and, at the same time, minimizing the perception gap between users and developers on project performance.
Abstract: Introduction It is commonly acknowledged that success in IT projects is difficult to achieve. A recent industry survey observed that only 34% of IT projects were considered successful. Of the several potential factors contributing to this hard-to-achieve success, user involvement was noted as the most important one. Consistent with this notion, both researchers and practitioners have viewed user participation as an important way of improving software quality and increasing user satisfaction and acceptance. Users/customers are often encouraged to participate and directly communicate with developers in the software development process. On the other hand, empirical evidence shows that user participation in the development process can negatively influence project performance since it could make the process more difficult, lengthy, and less effective. Such contradictory findings raise the question of when user participation is actually helpful and when it might negatively impact project performance. Previous research tells only one side of the story since it has examined user participation or project performance by focusing primarily on user viewpoints. The findings give an incomplete picture since they have not thoroughly addressed developer viewpoints. Clearly, there is a need to investigate software project success from the perspective of developers given that not only are they at the core of development process but they also represent the largest single cost in software development. Developer satisfaction is imperative for systems development success. Dissatisfied developers would adversely affect the quality of software as well as the productivity of development teams. A high rate of developer turnover in projects (due to dissatisfaction) could lead to increasing costs for development firms as well as high user/customer dissatisfaction. Due to the differences in background and circumstance, developers and users often share different and sometimes conflicting interests during software development. Researchers have identified a large gap in perceptions and definitions of project success between developers and the software industry (for example, users/customers). For example, developers tend to be achievement-oriented and are intrinsically motivated to develop excellent software, while users/ customers emphasis more on meeting a schedule or maintaining a budget. Thus, the potential conflicting interests between users and developers might negatively affect the software development performance. This article addresses the question of the relative effectiveness of user participation by empirically examining the perceived software project performance (for example, satisfaction) from both user and developer perspectives simultaneously. We used survey data from 117 software development projects and 746 respondents at a large Fortune 100 manufacturing firm during a four-year time period to investigate the impact of user participation on the satisfaction of both developers and users. Our findings offer insights into the impact of user participation on generating higher levels of developer and user satisfaction and, at the same time, minimizing the perception gap between users and developers on project performance. In addition, we also study the role of software complexity (for example, whether projects involve new software development as opposed to maintenance of existing software) in user participation and its effect on satisfaction. Questionnaire data was collected from 453 software developers and 293 users/customers working on 117 software projects (for details of the data collection process, see the sidebar "How the Survey was Conducted"). The average number of developer survey respondents per project (for example, team) was four and the average number of user/customer respondents per project was three. Our analysis was performed at project level, and satisfaction scores for developers and users were averaged for each project. Of the 117 software development projects, 45 (39% of our sample) were maintenance projects and 72 (61%) were new development projects. The average software development time of the 117 software projects was 126 days. Figure 1 outlines the project characteristics in our sample. The most common business domain for our software projects was the manufacturing and supply chain (41 projects, 35%) and most of the projects were Web-based applications (78 projects, 66%).

70 citations


Book
21 Jun 2010
TL;DR: Schaber, Ambler, Roman Pichler, and Matthew Wang as discussed by the authors present the first comprehensive, practical guide for Scrum practitioners working in large-scale distributed environments, which offers specific, actionable guidance for everyone who wants to succeed with Scrum in the enterprise.
Abstract: Succeed with Scrum in Even the Largest, Most Complex Distributed Development Projects Forewords by Ken Schwaber, Scott Ambler, Roman Pichler, and Matthew Wang This is the first comprehensive, practical guide for Scrum practitioners working in large-scale distributed environments. Written by three of IBMs leading Scrum practitionersin close collaboration with the IBM QSE Scrum Community of more than 1000 members worldwidethis book offers specific, actionable guidance for everyone who wants to succeed with Scrum in the enterprise. Readers will follow a journey through the lifecycle of a distributed Scrum project, from envisioning products and setting up teams to preparing for Sprint planning and running retrospectives. Each chapter presents a baseline drawn from conventional Scrum, then discusses additional issues faced by distributed teams, and presents specific best-practice solutions, alternatives, and tips the authors have identified through hard, empirical experience. Using real-world examples, the book demonstrates how to apply key Scrum practices, such as look-ahead planning in geographically distributed environments. Readers will also gain valuable new insights into the agile management of complex problem and technical domains. Coverage includes Developing user stories and working with Product Owners as a distributed team Recognizing and fixing the flaws Scrum may reveal in existing processes Engaging in more efficient Release and Sprint planning Conducting intense, brief daily Scrum meetings in distributed environments Managing cultural and language differences Resolving dependencies, performing frequent integration, and maintaining transparency in geographically distributed environments Successfully running remote software reviews and demos Brainstorming what worked and what didnt, to improve future Sprints This book will be an indispensable resource for every team leader, member, product owner, or manager working with Scrum or other agile methods in any distributed software development organization.

65 citations


Patent
18 Aug 2010
TL;DR: In this article, a user chooses a predesigned theme script to be applied to the user's assets to automatically create a story with a particular look and feel, and metadata and feature information is automatically gathered from the user assets to personalize the generated story.
Abstract: Automatic story production is implemented by the utilization of theme scripts with user assets to generate a quality finished product with minimum user input or direction. A user chooses a predesigned theme script to be applied to the user's assets to automatically create a story with a particular look and feel. Metadata and feature information, when available, is automatically gathered from the user assets to personalize the generated story. A user can include additional information and/or alter any aspect of the generated story to further personalize the resultant finished product.

63 citations


Book
03 Jun 2010
TL;DR: In this article, the authors present a process combining the best practices of Contextual Design, a leading approach to user-centered design, with those of Agile development, and describe strategies UX people can use to contribute effectively in an Agile team.
Abstract: With the introduction and popularization of Agile methods of software development, existing relationships and working agreements between user experience groups and developers are being disrupted. Agile methods introduce new concepts: the Product Owner, the Customer (but not the user), short iterations, User Stories. Where do UX professionals fit in this new world? Agile methods also bring a new mindset -- no big design, no specifications, minimal planning -- which conflict with the needs of UX design. This lecture discusses the key elements of Agile for the UX community and describes strategies UX people can use to contribute effectively in an Agile team, overcome key weaknesses in Agile methods as typically implemented, and produce a more robust process and more successful designs. We present a process combining the best practices of Contextual Design, a leading approach to user-centered design, with those of Agile development. Table of Contents: Introduction / Common Agile Methods / Agile Culture / Best Practices for Integrating UX with Agile / Structure of a User-Centered Agile Process / Structuring Projects / Conclusion

49 citations


Journal ArticleDOI
TL;DR: A UML profile that allows users to create executable Foundational UML (fUML) stories and scenarios is defined and a BDD model library which contains fUML activities for testing equalities and inclusions is introduced.

40 citations


Proceedings ArticleDOI
Sungjoo Kang1, Okjoo Choi1, Jongmoon Baik1
18 Aug 2010
TL;DR: A software cost estimation model for agile development which can help estimate concrete development costs for the desired features of a product and track the project progress dynamically by adopting the Kalman filter algorithm for tracking project progress.
Abstract: In this paper, we present a software cost estimation model for agile development which can help estimate concrete development costs for the desired features of a product and track the project progress dynamically. In general, existing cost estimation methods for agile developments used a story point. Because it is relative value, the estimation results tend to be easily fluctuated by the small variation of the baseline story point. For tracking project’s progress, the velocity was measured to check the progress and was used to make plan for the iteration and the releases of the project. The proposed method in this paper provides the systematic estimation and dynamic tracking methodology for agile projects. To estimate the effort of a project development, function points are used in addition to the story point. The function points are determined based on the user stories of desired features of the product. We adopt the Kalman filter algorithm for tracking project progress. The remaining function points at a certain point during the project are modeled as the state space model for the Kalman filter. The daily variation of the function point is observed and inputted to the Kalman Filter for providing concrete estimation and velocity. Moreover we validate the better performance of our model by comparing with traditional methods through a case study.

39 citations


Book ChapterDOI
30 Mar 2010
TL;DR: The investigated project utilized the agile method eXtreme Programming and found genuine customer and user involvement in the design activities in the form of both direct and indirect participation in the agile development project.
Abstract: This paper contributes to the studies of design activities in information systems development. It provides a case study of a large agile development project and focusses on how customers and users participated in agile development and design activities in practice. The investigated project utilized the agile method eXtreme Programming. Planning games, user stories and story cards, working software, and acceptance tests structured the customer and user involvement. We found genuine customer and user involvement in the design activities in the form of both direct and indirect participation in the agile development project. The involved customer representatives played informative, consultative, and participative roles in the project. This led to their functional empowerment— the users were enabled to carry out their work to their own satisfaction and in an effective, efficient, and economical manner.

35 citations


Book
22 Dec 2010
TL;DR: Lean-Agile Acceptance Test-Driven Development is an essential guide for lean-agile team members to define clear, unambiguous requirements while also validating needs with acceptance tests, and shows how to integrate essential requirements thinking, user acceptance tests and sounds, and lean- Agile practices, so you can deliver product requirements correctly and efficiently.
Abstract: Praise for Lean-Agile Acceptance Test-Driven DevelopmentLean-Agile Acceptance Test-Driven Development tells a tale about three fictive project stakeholders as they use agile techniques to plan and execute their project. The format works well for the book; this book is easy to read, easy to understand, and easy to apply. Johannes Brodwall, Chief Scientist, Steria NorwayAgile development, some say, is all about pairing, and, yes, Im a believer in the power of pairing. After reading this book, however, I became a fan of the triadthe customer or business analyst + the developer + the tester, who work collaboratively on acceptance tests to drive software development. Ive written some patterns for customer interaction and some patterns for testing and I like what Ken Pugh has chosen to share with his readers in this down-to-earth, easy-to-read book. Its a book full of stories, real case studies, and his own good experience. Wisdom worth reading! Linda Rising, Coauthor of Fearless Change: Patterns for Introducing New IdeasThe Agile Manifesto, Extreme Programming, User Stories, and Test-Driven Development have enabled tremendous gains in software development; however, theyre not enough. The question now becomes How can I ensure clear requirements, correct implementation, complete test coverage, and more importantly, customer satisfaction and acceptance? The missing link is acceptance as defined by the customer in their own domain language. Lean-Agile Acceptance Test-Driven Development is the answer. Bob Bogetti, Lead Systems Designer, Baxter HealthcareKen Pughs Lean-Agile Acceptance Test-Driven Development shows you how to integrate essential requirements thinking, user acceptance tests and sounds, and lean-agile practices, so you can deliver product requirements correctly and efficiently. Kens book shows you how table-driven specification, intertwined with requirements modeling, drives out acceptance criteria. Lean-Agile Acceptance Test-Driven Development is an essential guide for lean-agile team members to define clear, unambiguous requirements while also validating needs with acceptance tests. Ellen Gottesdiener, EBG Consulting, www.ebgconsulting.com, Author of Requirements by Collaboration and The Software Requirements Memory JoggerIf you are serious about giving Agile Testing a chance and only have time to read one book, read this one. David Vydra, http://testdriven.comThis book provides clear, straightforward guidance on how to use business-facing tests to drive software development. Im excited about the excellent information in this book. Its a great combination of the authors experiences, references to other experts and research, and an example project that covers many angles of ATDD. A wide range of readers will learn a lot that they can put to use, whether they work on projects that call themselves lean or agile or simply want to deliver the best possible software product. Lisa Crispin, Agile Tester, ePlan Services, Inc., Author of Agile TestingWithin the framework of Acceptance Test-Driven-Development (ATDD), customers, developers, and testers collaborate to create acceptance tests that thoroughly describe how software should work from the customers viewpoint. By tightening the links between customers and agile teams, ATDD can significantly improve both software quality and developer productivity. This is the first start-to-finish, real-world guide to ATDD for every agile project participant. Leading agile consultant Ken Pugh begins with a dialogue among a customer, developer, and tester, explaining the what, why, where, when, and how of ATDD and illuminating the experience of participating in it. Next, Pugh presents a practical, complete reference to each facet of ATDD, from creating simple tests to evaluating their results. He concludes with five diverse case studies, each identifying a realistic set of problems and challenges with proven solutions. Coverage includes How to develop software with fully testable requirements How to simplify and componentize tests and use them to identify missing logic How to test user interfaces, service implementations, and other tricky elements of a software systemHow to identify requirements that are best handled outside software How to present test results, evaluate them, and use them to assess a projects overall progress How to build acceptance tests that are mutually beneficial for development organizations and customers How to scale ATDD to large projects

34 citations


Book
25 Sep 2010
TL;DR: The Agile Samurai slices away the fluff and theory that make other books less-than-agile and gives you the insight and foundation necessary to become a valuable agile team member.
Abstract: Get ready to kick some software project butt. By learning the ways of the agile samurai you will discover: * how to create plans and schedules your customer and your team can believe in what characteristics make a good agile team and how to form your own how to gather requirements in a fraction of the time using agile user stories what to do when you discover your schedule is wrong, and how to look like a pro correcting it how to execute fiercely by leveraging the power of agile software engineering practices By the end of this book you will know everything you need to set up, execute, and successfully deliver agile projects, and have fun along the way. If you're a project lead, this book gives you the tools to set up and lead your agile project from start to finish. If you are an analyst, programmer, tester, usability designer, or project manager, this book gives you the insight and foundation necessary to become a valuable agile team member.The Agile Samurai slices away the fluff and theory that make other books less-than-agile. It's packed with best practices, war stories, plenty of humor and hands-on tutorial exercises that will get you doing the right things, the right way.This book will make a difference.

Book ChapterDOI
17 Oct 2010
TL;DR: Examining user stories through the dual lenses of an innovation space and the five SECI enablers concludes that expressing user needs as user stories can support the development of innovative solutions, but that care must be taken in the design of the user stories and their application.
Abstract: The concept of an innovation space where different knowledge and perspectives can interact leading to innovation is central to lean thinking. The SECI framework of organizational knowledge creation identifies five enabling conditions which impinge on this space, namely intent, autonomy, fluctuation, redundancy and variety. User Stories, introduced in XP and now commonly used in Scrum, are a key practice in requirements capture. In common with lean thinking, they are user value centric, encourage rich dialogue between project stakeholders and avoiding premature specification of solutions. This conceptual paper examines user stories through the dual lenses of an innovation space and the five SECI enablers. The authors conclude that expressing user needs as user stories can support the development of innovative solutions, but that care must be taken in the design of the user stories and their application. This paper concludes with a set of recommendations to support innovation through user stories.

Book ChapterDOI
01 May 2010
TL;DR: The development of interactive systems typically involves the separate design and development of disparate system components by different software developers and the user interface is the part of an interactive system through which a user can access the system functionality.
Abstract: The development of interactive systems typically involves the separate design and development of disparate system components by different software developers. The user interface (UI) is the part of an interactive system through which a user can access the system functionality. User interface development is a complex task that typically involves the construction of prototypes and/or models. A prototype facilitates the communication with the stakeholders, especially with the end users, and allows for the validation of elicited requirements. Modelling is a well established way people take for dealing with complexity. A model allows one to focus on important properties of the system being modelled and abstract away from unimportant issues. Software models may capture relevant parts of the problem and solution domains and are typically used as a means for reasoning about the system properties and for communicating with the stakeholders. The user interface tends to be viewed differently, depending on what community the UI designer belongs to. UI designers that are more identified with the Software Engineering (SE) community tend to highlight the system functionality issues, and how it encapsulates system behaviour to provide to the user. UI designers that are more identified with the Human-Computer Interaction (HCI) community tend to focus on user task analysis and the way the user shall work on the UI. According to the HCI perspective, one of the concerns that shall be modelled is the user intended tasks on the interactive system, and this is made through the development of user task analysis. Typically, task analysis and modelling involve the development of goal and task hierarchies and the identification of objects and actions involved in each task (Dix et al., 1998). Besides this task model, a view of the UI relevant aspects of the system core structure and functionality may also be modelled, along with a UI presentation model, in order to complete the whole interactive system model. In the SE community, a common practice is to build a Unified Modelling Language (UML) system model, comprising a domain model and a use case model, supplemented by a non-functional UI prototype, in the early stages of the software development process (Jacobson et al., 1999; Pressman, 2005). The domain model captures the main system’s domain classes, its attributes, relations and, in some cases, its operations, through UML class diagrams. The use case model captures the main system functionalities from the user’s point of view

Book ChapterDOI
23 Jun 2010
TL;DR: An innovative concept is presented showing that using a supervised text mining approach, COSMIC functional size can be automatically approximated from informally written textual requirements, demonstrating its applicability in popular agile software development processes, such as Scrum.
Abstract: Measurement of software size from user requirements is crucial for the estimation of the developmental time and effort. COSMIC, an ISO/IEC international standard for functional size measurement, provides an objective method of measuring the functional size of the software from user requirements. COSMIC requires the user requirements to be written at a level of granularity, where interactions between the internal and the external environments to the system are visible to the human measurer, in a form similar to use case descriptions. On the other hand, requirements during an agile software development iteration are written in a less formal way than use case descriptions -- often in the form of user stories, for example, keeping with the goal of delivering a planned release as quickly as possible. Therefore, size measurement in agile processes uses methods (e.g. story-points, smart estimation) that strictly depend on the subjective judgment of the experts, and avoid using objective measurement methods like COSMIC. In this paper, we presented an innovative concept showing that using a supervised text mining approach, COSMIC functional size can be automatically approximated from informally written textual requirements, demonstrating its applicability in popular agile software development processes, such as Scrum.

Journal ArticleDOI
TL;DR: This paper introduces a technique that aims to achieve the benefits of acceptance testing within large-scale development projects that deploy a V-model development process, specifically those that utilize use case models.
Abstract: In agile development processes, the rewards from acceptance testing are maximized by using the practice to drive the development process. Traditionally, User Stories are used in agile projects to describe a system’s usage scenarios and are utilized as a basis for developing acceptance tests. This paper introduces a technique that aims to achieve the benefits of acceptance testing within large-scale development projects that deploy a V-model development process, specifically those that utilize use case models. The approach is based on utilizing a number of artifacts: use case models supported by robustness diagrams and domain models. The feasibility of the proposed approach is demonstrated by applying it to a real-world system—the RestoMapper system. The results show that a comprehensive set of acceptance tests can be developed based upon use case models.

Book ChapterDOI
01 Jun 2010
TL;DR: This paper presents a systematic and lightweight method to identify dependencies between user stories, aiding in the reduction of their impact on the overall project cost.
Abstract: The order in which user stories are implemented can have a significant influence on the overall development cost. The total cost of developing a system is non commutative because of dependencies between user stories. This paper presents a systematic and lightweight method to identify dependencies between user stories, aiding in the reduction of their impact on the overall project cost. Initial architecture models of the software product are suggested to identify dependencies. Using the method proposed does not add extra load to the project and reinforces the value of the architecture, facilitates the planning and improves the response to changes.

01 Jan 2010
TL;DR: In this paper, the authors present a guideline for sizing Agile projects with the COSMIC method, along with a summary of the resulting guideline, and describe the expected requirements format and their measurement practices.
Abstract: Agile became one of the most used ‘buzzwords’ in ICT projects in these recent years but the growing diffusion and interest of its related methods and techniques was not accompanied by the same maturity in sizing and estimation practices. In particular the application of a functional size measurement (FSM) method for sizing requirements is not typical to ”agilists”, preferring to use mostly estimations based on experience and analogy. In such way, one of several drawbacks is a reduced data gathering from projects, not allowing to do (even at a basic level) statistical analysis, for better estimating the proper efforts value for next user story and – as a whole – of the project. This paper describes the reasons why a guideline for sizing Agile projects with the COSMIC method was required, along with a summary of the resulting guideline. Several agile methods are briefly described, more specifically their expected requirements format and their measurement practices.

01 Jan 2010
TL;DR: This work investigates benefits from adopting a standardized Functional Size Measurement (FSM) method, such as COSMIC Function Points, in place of Story Points, and using a Transfer Function that transforms size into effort spent within a particular agile team, defect density prediction can be made using sensitivity analysis.
Abstract: The spreading of agile methodologies in software development raises the question of how to measure requirements once more, as it happened in ‘traditional’ software industry development approaches decades ago. The difference is that requirements are not known in advance but detected as User Stories while iterating and enhancing the software product from one agile ‘Sprint’ to the other. Some authors – promoting best practices for agile software development – propose Story Points to size User Stories (e.g., Scrum, with Story Cards), yet not combined with base project estimation. Story Points are not standardized, thus leading to eventual misconceptions and quantitative differences among practitioners and domains. The uncertainty implied in such approach can therefore propagate to any estimate based on it, not to mention the difficulty in accurately tracing requirements and their variation over the project and across project iterations. This work investigates benefits from adopting a standardized Functional Size Measurement (FSM) method, such as COSMIC Function Points, in place of Story Points. Using a Transfer Function (from the Six Sigma practice) that transforms size into effort spent within a particular agile team, defect density prediction can be made using sensitivity analysis.

Book ChapterDOI
01 Jun 2010
TL;DR: This paper presents and evaluates a technique for automatically relating emails with user stories based on their text and context similarity and shows how Agile project management tools can use this technique to automatically build a knowledge base that is otherwise costly to produce and maintain.
Abstract: In distributed agile teams, people often use email as a knowledge sharing tool to clarify the project requirements (aka user stories). Knowledge about the project included in these emails is easily lost when recipients leave the project or delete emails for various reasons. However, the knowledge contained in the emails may be needed for useful purposes such as re-engineering software, changing vendor and so on. But, it is difficult to relate texts such as emails to certain topics because the relation is not explicit. In this paper, we present and evaluate a technique for automatically relating emails with user stories based on their text and context similarity. Agile project management tools can use this technique to automatically build a knowledge base that is otherwise costly to produce and maintain.

Book ChapterDOI
01 Jan 2010
TL;DR: This chapter covers challenges faced by the project teams of two pilot projects, including strengths of using agile practices in a globally distributed environment and practical recommendations for similar endeavors.
Abstract: Global companies that experienced extensive waterfall phased plans are trying to improve their existing processes to expedite team engagement. Agile methodologies have become an acceptable path to follow because it comprises project management as part of its practices. Agile practices have been used with the objective of simplifying project control through simple processes, easy to update documentation and higher team iteration over exhaustive documentation, focusing rather on team continuous improvement and aiming to add value to business processes. The purpose of this chapter is to describe the experience of a global multinational company on transitioning from distributed and traditional to distributed and agile. This company has development centers across North America, South America and Asia. This chapter covers challenges faced by the project teams of two pilot projects, including strengths of using agile practices in a globally distributed environment and practical recommendations for similar endeavors.

Book ChapterDOI
01 Jun 2010
TL;DR: The main objective is to assist the use of Acceptance Test-Driven Development (ATDD) in web applications by providing mechanisms to support customer-developer communication and by helping test case creation.
Abstract: This paper proposes an approach for modeling and executing acceptance web test cases and describes a suite of tools to support it. The main objective is to assist the use of Acceptance Test-Driven Development (ATDD) in web applications by providing mechanisms to support customer-developer communication and by helping test case creation. Initially, the set of web pages and relations (links) associated with a user story is modeled. Functional test possibilities involving these relations are automatically summarized in a graph, being each path of the graph a user story testing scenario. Once a testing scenario is accepted by the customer, a testing script is automatically created. A web testing framework then executes the script, triggering the ATDD process.

Proceedings ArticleDOI
01 Jan 2010
TL;DR: It is discovered that the user perception of a product concept is not only the opposite of the one of the designer but in fact also much wider, and the users ended up modeling a coherent whole — their overall experience relating to the product concept.
Abstract: When developing new products, it is crucial to consider user needs The designer is not the user, and thus understanding what users truly need can be difficult A key for understanding is to comprehend, how the users fundamentally perceive a product Designer’s and user’s perceptions of a product differ, and with this in mind, we developed and tested a method for capturing user’s and designer’s perspectives of an existing product or service concept As we tested this Participatory 3D modeling method, we discovered that the user perception of a product concept is not only the opposite of the one of the designer but in fact also much wider Instead of concentrating on the product itself, the users ended up modeling a coherent whole — their overall experience relating to the product conceptCopyright © 2010 by ASME

Book ChapterDOI
01 Jan 2010
TL;DR: This chapter illustrates some of the typical challenges that were met during real-world commercial projects, and how they were solved.
Abstract: Two trends are becoming widespread in software development work—agile development processes and global delivery, both promising sizable benefits in productivity, capacity and so on. Combining the two is a highly attractive possibility, even more so in fast-paced and constrained commercial software engineering projects. However, a degree of conflict exists between the assumptions underlying the two ideas, leading to pitfalls and challenges in agile/distributed projects which are new, both with respect to traditional development and agile or distributed efforts adopted separately. Succeeding in commercial agile/distributed projects implies recognizing these new challenges, proactively planning for them, and actively put in place solutions and methods to overcome them. This chapter illustrates some of the typical challenges that were met during real-world commercial projects, and how they were solved.

Book ChapterDOI
Thomas Stober1, Uwe Hansmann1
01 Jan 2010
TL;DR: The five principles of a fractal team, which were introduced in Chap.
Abstract: Agile thinking is an attempt to simplify things by reducing complexity of planning, by focusing on customer value, and by shaping a fruitful climate of participation and collaboration. There are a vast number of methods, techniques, best practices, that claim to be “agile.” In this chap. we want to give an overview of the most common ones. The five principles of a fractal team, which we introduced in Chap. 1, apply to most of them: self-similarity, goal orientation, self organization, self improvement, and vitality are cornerstones when implementing an organization capable of executing software projects in an agile way. The desire to establish flexible and efficient development processes which produce high quality results is not new and has not only been applied to software development: More than two decades ago, the manufacturing industry underwent dramatic changes, when the traditional production concepts of Taylor and Ford were challenged by extremely successful Japanese enterprises such as Toyota. The Western hemisphere was puzzled at how the competition from Far East seemed to be able to produce better quality at lower cost and quickly began to outperform the rest of the world. What happened? What was the secret of the amazing efficiency and innovation?

Proceedings Article
08 Jul 2010
TL;DR: In this paper, a multi-step framework is presented to involve caregivers in the initial phase of a design process of a telecare system, based on contextual design and user centered design methods, supported by an evolving set of scenarios.
Abstract: Telecare systems show the potential for elderly to remain in-home for a longer period by increasing early detection of behavioural changes and adapt home care delivery. As 37% of the telecare initiatives fail due to a lacking user acceptance of the technology, involving users in the design process and taking their needs as onset for design is regarded as a prerequisite. However involving caregivers as contemplated users in the design process raises several barriers. Caregivers are overall technically illiterate, unable to address their needs for technology and their involvement faces a vocabulary gap with developers. Secondly, the fuzzy process of needs elicitation and translating these into formal requirements is part of the challenge to overcome this mutual vocabulary gap. Our work presents a practical multi-step framework to involve caregivers in the initial phase of a design process of a telecare system. The framework is deployed to conceptually design an activity monitoring system to support informal and professional caregivers in home care delivery for solitary in-home demented persons. Methods A multi-step framework was deployed based on contextual design and user centered design methods, supported by an evolving set of scenarios. Based on a contextual study in home care delivery a user story was written and used as onset for eliciting caregivers’ needs in a workshop. Secondly, functional requirements (FR’s) and non-functional requirements (NFR’s) were defined based on caregivers’ evaluation of a conceptual scenario and mock-ups that were generated based on the insights from the workshop. Results and discussion In the three hours workshop the user story leaded to a clear discussion and prioritization of needs, whereas caregivers (n=9) underlined the need for technology to improve the quality of home care delivery. The two most important activities, eating and drinking and sleeping, were selected by the group for further development. The conceptual scenario and mock-ups were insightful for caregivers (n=5) and they were able to constructively evaluate and (re)define a set of 28 FR’s and 7 NFR’s. The FR’s were defined qualitatively and reflected the functionality of the system in terms of specific activities to monitor, generic data transmission functions and method of presenting the information (interface). The NFR’s were often articulated as concerns regarding the contemplated system and reflected practical concerns for the demented persons (e.g. non-wearable sensors, unobtrusiveness) and the caregivers work activities (e.g. ease of use, validity of information). The NFR’s are used as design criteria to make design choices in the following step towards a system architecture. This study showed that scenarios enabled us to elicit unarticulated needs of caregivers and evaluate FR’s and NFR’s. Secondly, scenarios enabled caregivers to understand and respond to technical concepts in order to constructively involve them in the design process. A future challenge is to translate needs to requirements in a workshop involving both caregivers and technicians in order to define requirements quantitatively, using scenarios as a common platform for discussion. []

Patent
08 Nov 2010
TL;DR: In this article, a user interface mechanism is defined by a story from which a wizard engine may create user interfaces, using various user interface containers that define a layout and general functions of user interface, along with styles that may define the look and feel of the user interface.
Abstract: A user interface mechanism may be defined by a story from which a wizard engine may create a user interface. The engine may present the story using various user interface containers that define a layout and general functions of a user interface, along with styles that may define the ‘look and feel’ of the user interface. The story may define an action performed once data are collected from the user. The story may also define data passed to the action, as well as the data collected from a user. The story may further define translation routines or other actions that may be launched in response to receiving user action and used to generate data that may be passed to the action.

Proceedings ArticleDOI
01 Oct 2010
TL;DR: The main challenges of implementing fixed-price agile projects for corporate customers’ deals with the difficulties development teams encounter in delivering fixed- Price Agile projects for traditional corporate clients.
Abstract: This experience report titled, ‘The main challenges of implementing fixed-price agile projects for corporate customers’ deals with the difficulties development teams encounter in delivering fixed-price agile projects for traditional corporate clients. The report also lays out the rationale for the agile approach to fixed-price contracts, and cites examples of successful implementations.

Proceedings ArticleDOI
01 Dec 2010
TL;DR: The present article is about the different ways of involving the user in designing the products in order to open a new window, which causes specific vision and determines the hidden perspectives of the user desire and its environment.
Abstract: Due to the change of social conditions and economical and cultural aspects, user's expectation has been changed too Today for users, satisfying the emotional and feeling needs towards products is most important point The recent human psychological studies suggest that having an experience and good feeling with products is the main factor for making decisions Hence, designers try to understand those hidden needs of people In this way, they can make a special kind of user's satisfaction During this process, all possible relationships between the user and the product and all factors that are involved in its interaction are analyzed In the final stage, current technologies, user experiences, feelings and imaginations are applied in designing the product The present article is about the different ways of involving the user in designing the products in order to open a new window, which causes specific vision and determines the hidden perspectives of the user desire and its environment

Patent
04 Mar 2010
TL;DR: In this paper, a system and method for connecting a user to business services monitors all attempts by the user to place outgoing telephone calls, and checks to see if the business has created a voice application that could be performed for the user.
Abstract: A system and method for connecting a user to business services monitors all attempts by the user to place outgoing telephone calls. When a user is attempting to place a call to a business, the system checks to see if the business has created a voice application that could be performed for the user. If so, the business' voice application is performed for the user on the user's local device, instead of connecting the user to the business' customer service line. If no voice application is available for the user, then the system connects the user to the business' customer service line, either through a telephone network, or through a data network connection.

Book ChapterDOI
01 Jan 2010
TL;DR: The Pomodoro Technique as discussed by the authors is one promising time management technique for distributed agile software development and its application and adaptation in Sourcesense Milan Team surfaced various benefits, challenges and implications for distributed software development.
Abstract: Time is one of the most important factors dominating agile software development processes in distributed settings. Effective time management helps agile teams to plan and monitor the work to be performed, and create and maintain a fast yet sustainable pace. The Pomodoro Technique is one promising time management technique. Its application and adaptation in Sourcesense Milan Team surfaced various benefits, challenges and implications for distributed agile software development. Lessons learnt from the experiences of Sourcesense Milan Team can be useful for other distributed agile teams to turn time from enemy into an ally.