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.

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.