Context: One of the most common artifacts in contemporary software projects is a product backlog comprising user stories, bugs, chores or other work items. However, little research has investigated how the backlog is generated or the precise role it plays in a project. Objective: The purpose of this paper is to determine what is a product backlog, what is its role, and how does it emerge? Method: Following Constructivist Grounded Theory, we conducted a two-year, five-month participant-observation study of eight software development projects at Pivotal, a large, international software company. We interviewed 56 software engineers, product designers, and product managers.We conducted a survey of 27 product designers. We alternated between analysis and theoretical sampling until achieving theoretical saturation. Results: We observed 13 practices and 6 obstacles related to product backlog generation. Limitations: Grounded Theory does not support statistical generalization. While the proposed theory of product backlogs appears widely applicable, organizations with different software development cultures may use different practices. Conclusion: The product backlog is simultaneously a model of work to be done and a boundary object that helps bridge the gap between the processes of generating user stories and realizing them in working code. It emerges from sensemaking (the team making sense of the project context) and coevolution (a cognitive process where the team simultaneously refines its understanding of the problematic context and fledgling solution concepts).

Context: Since software development is a complex socio-technical activity that involves coordinating different disciplines and skill sets, it provides ample opportunities for waste to emerge. Waste is any activity that produces no value for the customer or user. Objective: The purpose of this paper is to identify and describe different types of waste in software development. Method: Following Constructivist Grounded Theory, we conducted a two-year five-month participant-observation study of eight software development projects at Pivotal, a software development consultancy. We also interviewed 33 software engineers, interaction designers, and product managers, and analyzed one year of retrospection topics. We iterated between analysis and theoretical sampling until achieving theoretical saturation. Results: This paper introduces the first empirical waste taxonomy. It identifies nine wastes and explores their causes, underlying tensions, and overall relationship to the waste taxonomy found in Lean Software Development. Limitations: Grounded Theory does not support statistical generalization. While the proposed taxonomy appears widely applicable, organizations with different software development cultures may experience different waste types. Conclusion: Software development projects manifest nine types of waste: building the wrong feature or product, mismanaging the backlog, rework, unnecessarily complex solutions, extraneous cognitive load, psychological distress, waiting/multitasking, knowledge loss, and ineffective communication.

Context: One of the factors that leads to improved code maintainability is its readability. When code is difficult to read, it is difficult for subsequent developers to understand its flow and its side effects. They are likely to introduce new bugs while trying to fix old bugs or adding new features. But how do software developers know they have written readable code? Objective: This paper presents a new technique, Code Readability Testing, to determine whether code is readable and evaluates whether the technique increases programmers' ability to write readable code. Method: The researcher conducted a field study using 21 software engineering master students and followed the Code Readability Testing with each student in four separate sessions evaluating different "production ready" software. After the observations, a questionnaire evaluated the programmer's perspective. Results: By following Code Readability Testing, half of the programmers writing "unreadable" code started writing "readable" code after four sessions. Programmers writing "readable" code also improved their ability to write readable code. The study reveals that the most frequent suggestions for increasing code readability are improving variable names, improving method names, creating new methods in order to reduce code duplication, simplifying if conditions and structures, and simplifying loop conditions. The programmers report that readability testing is worth their time. They observe increases in their ability to write readable code. When programmers experience a reader struggling to understand their code, they become motivated to write readable code. Conclusion: This paper defines code readability, demonstrates that Code Readability Testing improves programmers' ability to write readable code, and identifies frequent fixes needed to improve code readability.

Many software engineering curriculum conclude with a practicum or capstone project course. For courses involving external clients, the course owner typically follows a Request for Proposal process to vet (or green-light) qualified clients and projects. Even though green-lighting projects does not guarantee project success, the goal is to reduce risks by systematically examining each proposal to identify potential problems that the instructor could solve, mitigate against, or simply decide not to deal with by rejecting the proposal. We propose and evaluate a Green-Lighting Approach based on the SEMAT (Software Engineering Method and Theory) Essence framework. Our objective is to identify if such a framework could improve the Request for Proposal process at Carnegie Mellon University in Silicon Valley and other universities. We conducted a case study by observing and interviewing the course owner, examining a group of proposals, and identifying issues with the current proposal process and practicum projects. We proposed a green-lighting project state that, based upon Essence Alphas, describes the minimal and ideal states that a project proposal should achieve to be accepted. The Green-Lighting Approach generated conversations among the faculty that clarified the guidelines for accepting and prioritizing proposals and identified deficiencies in our Request for Proposal. Additional work is required to refine the proposed Green-Lighting Approach based on current findings and further validate the approach. Using Essence for green-lighting practicum projects in academia presents some limitations. The framework does not explicitly factor in business forces that affect proposal selection, might be overly complex for the task, and might require modification with partial Alpha states. However, Essence provides a systematic approach for evaluating proposals based on various project dimensions. This approach could be used as an inspiration for deriving simpler custom green-lighting checklists.

Context: Team code ownership is a software development practice where any team member can modify any part of the team's code. However, many factors beyond official policy affect a developer's sense of ownership.

Context: Conventional wisdom says that team disruptions (like team churn) should be avoided. However, we have observed software development projects that succeed despite high disruption.

Background: Many software engineering curriculum contain a team-based project course. This is the case of Carnegie Mellon University Silicon Valley's masters of science in software engineering. In this context, we have been using Essence Reflection Meetings for five semesters with 17 teams and approximately 70 students. During these meetings, the teams reflect on various project's dimensions based on a systems thinking framework. The positive results have been published in research papers.Activity and Discussions: Participants will learn about Essence Reflection Meetings for team-based project courses by practicing in a classroom environment. They will discuss challenges and solutions for team-based project courses, and how the proposed approach could potentially be leveraged in their own teaching environment.Organization: We will start the workshop with a discussion revealing the participants positive and negative experiences with team-based projects. After briefly introducing the Essence's systems thinking framework and our research results, we will use hands-on training exercises to demonstrate how to use the approach. This will be followed with guided debriefing. Finally, we will go deeper into the Essence framework, and discuss our research results and their applicability in various teaching environments.Learning Objectives: By the end of the workshop, participants will be familiar with a systems thinking framework that they can leverage to coach their students teams and monitor their progress. They will be able to articulate the pros and cons of applying the approach in their own teaching environment.

This paper presents an empirical evaluation of the team reflection support provided by the Software Engineering Method and Theory (SEMAT) Essence framework, and compares Essence reflection meetings to other types of team reflection meetings. The researchers conducted a field study involving seven graduate master student teams running Essence reflection meetings throughout their practicum projects aiming at delivering a working product for an industry client. The main result validates that Essence meetings generate reflective team discussions through a thinking framework that is holistic, state-based, goal-driven, and method-agnostic. Student teams benefit from stepping back and assessing the project holistically throughout its lifecycle. The goals set by the framework's checklists lead the teams to address critical aspects of the project that have not been considered. All team members are encouraged to express their views and influence the various project dimensions. Essence reflection meetings are comparable and complementary to Agile retrospectives, and project teams might want to leverage both techniques. The value added by Essence reflections is to surface unknown issues, help monitor progress, steer the project to a higher state, and prevent retrospectives from being repetitive by varying styles.

This panel will discuss recent trends in graduate software engineering programs, including adoption of GSwE2009, cooperative programs between schools, increasing use of distance education formats, and specialization of programs for industry partners. Panelists will also discuss the evolving relationship of software engineering to other disciplines, such as computer science and systems engineering.

We believe the master's program in Software Engineering offered by Carnegie Mellon University's Silicon Valley Campus to be unique in that it is entirely team-based and project-centered [1]. Students learn by doing as they are coached just in time by faculty in the context of authentic projects, and they are evaluated on the work they produce. Student satisfaction is high: 94% believe that the program has given them a competitive advantage with respect to their professional peers, and their promotion and salary histories bear out this belief. This tutorial introduces the attendees to our learn-by-doing instructional approach through participation in a learn by doing experience, performing a usability analysis of a commercial website, followed by discussion to highlight what we believe to be important principles of teaching by coaching.

This paper presents the initial results of a study of the evolution of students' knowledge of software engineering from the beginning to the end of a master's degree curriculum in software engineering. Students were presented with a problem involving the initiation of a complex new project at the beginning of the program and again at the end of the program's formal coursework. After considering the problem each time, students were asked what questions they had as the senior software engineer, which software engineering processes need to be put into place, and to enumerate any other issues they saw. Statistical analysis indicates that their enumeration of software processes in the post condition is very significantly richer than in the pre condition. They also gave significantly more responses about requirements, design, and engineering management in the post condition. Qualitative analysis suggests that the students' questions in these areas were also more sophisticated in the post condition, suggesting, in accordance with the theory of "transfer as preparation for future learning," that they are moving along a trajectory towards expertise.

We report on the experience of the first offering of the course, "The Craft of Software Development." The purpose of the course is to identify and remediate individual weaknesses as software developers. Each student was asked to pick a personal learning focus in an area of known software development weakness for that student. Through a "maiden speech" they asked their class community for help in creating a learning plan to address their area of weakness. Learning plans typically incorporated known apprenticeship patterns such as "Find a Coach," "Breakable Toys," and "Practice, Practice, Practice." After creating their learning plan, students identified metrics to track their progress towards their goal. While executing their individual learning plans, the class performed programming katas which are specific programming exercises to work on issues relevant for the entire class. Several issues emerged in the first offering in the course and several suggestions are provided for incorporation in the next offering of the course.

Waterfall and Extreme Programming are two software project methods used for project management. Although there are a number of opinions comparing the two methods regarding how they should be applied, none have used project data to clearly conclude which one is better. In this paper, we present the results of a controlled empirical study conducted at Carnegie Mellon University in Silicon Valley to learn about the effective transition from traditional development to agile development. We conducted a comparison research against these two approaches. Multiple teams were assigned a project; some used Waterfall development, others used Extreme Programming. The purpose of this research is to look at advantages and disadvantages based upon the outcomes, generated artifacts, and metrics produced by the teams.