Cecile Peraire

The 4C Model for Defining User Stories: Context, Card, Conversation, and Confirmation

Writing user stories that effectively support software product development is difficult for students new to the practice. At ICSE’23, during the 5th International Workshop on Software Engineering Education for the Next Generation (SEENG), I presented a position paper addressing this challenge by extending the existing 3C model for defining user stories with an extra C for ‘context’. This format is targeted to interactive software systems and inspired by a grounded theory research study where the observed product managers provided context by basing most user stories on concrete and validated design artifacts, such as wireframes.

The 4C Model

In addition to defining user stories using the existing 3C model (Card, Conversation, and Confirmation), I ask my students to start defining a user story by first providing its context (as illustrated in Figure 1).

Fig. 1. The 4 C’s of user stories: (concrete and validated) Context, Card, Conversation, and Confirmation.

The user story context is defined by:

The name of the larger feature or epic that encompasses the story.
A meaningful name for the story summarizing the covered behavior.
A concrete and validated design artifact from which the story can be derived (if applicable). The design artifact visually represents a concrete idea for the solution, like a wireframe. It has been validated by stakeholders (see more on that below). It provides the team with a shared understanding of the story’s context and serves as a starting point to derive the story Card, Conversation, and Confirmation. Note that more than one story could potentially be derived from the same design artifact.

The concrete and validated design artifact also reminds students that a creative process needs to occur BEFORE one starts specifying user stories with acceptance criteria. Concrete visual design artifacts (like sketches or wireframe) are effective at supporting the creative process because they allow us to refine our understanding of the problem and the solution at the same time (which is important because it is impossible to fully understand the problem before moving to the solution). On the contrary, user stories with acceptance criteria are abstract textual artifacts that poorly support the creative process and are more helpful at guiding implementation.

Extended INVEST Criteria

In addition to satisfying the well-known INVEST criteria (Independent [when possible], Negotiable, Valuable, Estimable, and Small), each user story should satisfy the following additional criteria:

Contextualized: The story is situated in its broader context via a concrete design artifact. It is straightforward to understand the story relationships with its encompassing feature or epic and surrounding stories.
Understandable: The behavior covered by the story is easy to understand by stakeholders, especially by developers in charge of implementation (and by faculty and teaching assistants in charge of evaluating the story).
Validated: Stakeholders have validated that the encompassing feature or epic satisfies their needs: The feature or epic is useful, usable, and delightful from a user perspective, competitive from a business perspective, and feasible from a technical perspective. This extends the INVEST ‘Valuable’ criterion. The idea is to identify problems very early on, before writing detailed user stories or code, in order to reduce rework.

Example

Figure 2 presents an example of the application of the 4C model.

Fig. 2. The 4 C’s of user stories: An example

The above story is contextualized (it belongs to the Donate Items epic and is related to the provided wireframe), understandable (the behavior covered is easy to comprehend) and satisfies the stakeholders’ needs (assuming that the wireframe has been properly validated by stakeholders).

Conclusion

After experimenting with the 4C model during four semesters with positive initial results, I posit that the model helps students generate stories that are easier to create and review while supporting the development of innovative solutions that satisfy the stakeholders’ needs. However, this conclusion is based on expert judgment and anecdotal evidence. Further research is necessary to rigorously evaluate the effectiveness of the proposed 4C model.

Reference

This blog is a short summary of the following position paper:

Cécile Péraire. “Learning to Write User Stories with the 4C Model: Context, Card, Conversation, and Confirmation” IEEE/ACM 5th International Workshop on Software Engineering Education for the Next Generation (SEENG) at ICSE’2023 (2023).

Related Posts

SEENG 2021 Software Engineering Education Workshop: Report

by Cécile Péraire and Stephan Krusche

The Third International Workshop on Software Engineering Education for the Next Generation (SEENG 2021) was held remotely on May 24, 2021. The workshop was an integral component of the Joint Track on Software Engineering Education and Training (JSEET) at the 43rd IEEE/ACM International Conference on Software Engineering (ICSE). It specifically supported the JSEET’s theme of Educating the Next Generation of Software Engineers:

“Millennials and Generation Z have been dominating higher education programs for some time. In a decade, our classes will be hosting Generation Alpha. We have all noticed that these cohorts have unique needs and different learning styles, social behaviors, and skills. With their increasing mobility, our classes will become more and more diverse. Our students will become increasingly collaborative, socially aware, tech-savvy, multi-disciplinary, and interested in emerging technologies. How shall the software industry capitalize on the mix of qualities that the new breed of software engineers will possess? How shall software engineering educators effectively and equitably cater to the students’, society’s, and industry’s evolving and diverse interests while ensuring that the next generation of software engineers learn the timeless principles, have a firm grounding in both software engineering theory and practice, behave responsibly, and make a positive contribution to the society?”

Following the First International Workshop on Software Engineering Curricula for Millennials (SECM 2017) and Second International Workshop on Software Engineering Education for Millennials (SEEM 2018), our goal in this third edition was to continue to bring together main stakeholders to discuss the unique needs and challenges of software engineering education for the next generation, including software engineering educators and representatives of STEM education. Building on its predecessors, the workshop used a highly interactive format, structured around short presentations to generate discussion topics, an activity to select the most interesting topics, and structured breakout sessions to allow participants to address those topics.

We solicited position papers addressing a variety of related topics that include: software engineering education for new and emerging technologies; novel approaches to designing software engineering curricula; skills and continuing education for software engineering educators; classroom formats that cater to diverse learning styles; teaching approaches that leverage technology-enhanced education in software engineering courses; balancing teaching of soft and hard skills; rigor and practicality in software engineering education; and experience in educating students in software engineering programs.

The diverse international program committee consisted of 21 software engineering educators and researchers from academia and industry across 12 different countries. The submission process was competitive. Each paper was evaluated by at least 3 reviewers. Eight position papers out of 20 submissions were accepted (40% acceptance rate). The contributions span a variety of topics, including project-based courses, teaching design by contract, software testing approaches, student feedback and assessment practices, and more.

The ulterior motive with this third edition of SEENG was to continue to grow a community excited about and dedicated to serving the next generation of students. 26 participants registered to the workshop and 18 of them joined via Zoom to share their thoughts, insights, and experiences, seek and offer advice on pedagogical methods that work, and explore collaboration opportunities on new software engineering education initiatives.

The workshop agenda was based on the structure and practices proposed in Designing Interactive Workshops for Software Engineering Educators with some adaptations for a remote setting, including the use of an online collaborative whiteboard platform called Miro.

Workshop collaboration was supported by the Miro online collaborative whiteboard platform

The workshop started with a brief introduction of all the participants using visual slides.

Visual slides used by the workshop participants to briefly introduce themselves

It continued with a series of brief 5-minute presentations of the accepted papers to remind everyone of the problems we face, and learn how others have been solving those problems. To identify common interests, participants were asked to capture any interesting insights from the presentations on virtual post-it notes in Miro.

Based on the insights gathered during the presentations, we then performed an affinity mapping activity to identify and select discussion topics. The topics that emerged as of most interest to the participants were: Team-based Learning, Automatic Assessment, and Specification and Verification.

Affinity map created by participants based on what they learned during the presentations (created in Miro)

Participants were then divided into breakout groups to discuss the selected topics further. For each topic (Team-based Learning, Automatic Assessment, and Specification and Verification), the breakout group participants were asked to define a Big Hairy Audacious Goal (BHAG), or very ambitious goal. For their BHAG, group participants created a Mind Map to brainstorm WHAT success looks like and HOW to achieve success. Finally, each breakout group presented its mind map to all the workshop participants. Here are the resulting mind maps.

Mind Map for Team-based Learning (created in Miro)

Mind Map for Automatic Assessment (created in Miro)

Mind Map for Specification and Verification (created in Miro)

We closed the workshop with a retrospective and identification of future action items.

Outcome of the workshop retrospective (done in Miro)

The feedback was overwhelmingly positive, with participants appreciating the interactive workshop format, use of the Miro collaboration tool, short presentations, and the opportunity to discuss with peers despite the covid-19 pandemic. The main improvement suggestion was that the discussion period could have been longer. Some of the action items identified included using the workshop’s blog to present the results of the breakout sessions and to summarize and promote the SEENG papers.

Acknowledgment: We would like to thank the program committee members for their work and selection of high-quality papers. We would also like to thank all participants for attending the third edition of ICSE’s software engineering education workshop. The workshop was a success thanks to your enthusiasm, active participation, insights, and experiences.

Announcing the SEENG 2021 Workshop

We are please to announce the Third International Workshop on Software Engineering Education for the Next Generation!

SEENG 2021 will be held in Madrid, Spain. It will be an integral component of the Joint Track on Software Engineering Education and Training (JSEET) at the 43rd IEEE/ACM International Conference on Software Engineering (ICSE).

The Call for Papers is available on the JSEET website, where we invite you to submit a position paper of maximum 4 pages containing a position statement and your profile, plus a single page of references.

Note that we would love to see authors participate in both the main JSEET track and SEENG workshop. Hence we encourage authors to submit both a “long” paper (research, experience, idea, and tool paper) to the main JSEET track AND a position paper to the SEENG workshop.

We look forward to seeing you in Madrid!

Dual-Track Agile in Software Engineering Education

In the previous post, related to my ICSE’19 paper on Dual-Track Agile in Software Engineering Education [1], I focussed on the question: Why do we need to teach Interaction Design to Software Engineering students?

This post addresses the next question: How could we teach Interaction Design while staying away from “Big-Design-Up-Front”?

The proposed answer is situated in the context of a course aimed at enabling students (who are doing a Master of Science in Software Engineering at Carnegie Mellon University in Silicon Valley) to design and implement software systems that at once useful, usable, and enjoyable to use, while making a unique contribution to society. This is done by introducing Interaction design (IxD) and Software Product Management (PM) in the context of dual-track agile.

Note that I am referring to Software Product Management (PM) versus Requirement Engineering (RE) simply because nowadays product managers are often the ones who write and prioritize requirements (like user stories), with a goal of organizing the work to support development.

Introducing New Practices

Teaching IxD requires introducing new practices, including for instance Contextual Inquiry, Affinity Mapping, Persona Modeling, Storyboarding, Design Walkthrough, Brainstorming, Ideation, How-Might-We, Sketching, Prototyping, Think-Aloud Usability Testing, Usability Testing, Heuristic Evaluation, Style Guide, and so on.

For students, like mine, who have some experience in software development but no experience with IxD, learning those practices could be challenging and time consuming (specially when they involve collaborating with stakeholders). So leaning to apply the practices effectively is going to take most of the semester, with limited time for implementation and iterations. Given that situation, the challenge is: How do we stay away from teaching “Big-Design-Up-Front”?

Staying Away from “Big-Design-Up-Front”

When I first joined Carnegie Mellon University in 2012, I taught an existing course on Requirements Engineering that introduced some IxD practices with no implementation. As a result, and even though no specific software development process was mentioned, the students’ perception was that we were talking about “Big-Design-Up-Front”.

To address the problem, when asked to create my own new course in 2015, I decided to add the implementation of a Minimum Viable Product (MVP) and to frame the work in the context of an iterative process. I called this process the Double-Wheel, as it was my adaptation of the Wheel from the UX Book [2], with IxD practices covered in the first wheel and the implementation of the MVP in the second wheel. However, because the new IxD practices and MVP implementation were done sequentially during the course project, the perception was still “Big-Design-Up-Front” for some students.

Finally, last semester, following an empirical study at a company called Pivotal Software [3], I replaced the Double-Wheel with Dual-Track Agile, to better reflect what we observed in industry, and I introduced some concurrency between the IxD practices and the MVP implementation. Even though the concurrency was only minimum, these changes managed to eventually shift the perception away from“Big-Design-Up-Front”.

Introducing Dual-track Agile

To introduce dual-track agile in the classroom I came-up with a model that simplifies the messy reality for students, as illustrated in Figure 1.

Fig.1: A simple model of Dual-Track Agile for students

The model includes two tracks. The first track is about discovering what functionality to build. The second track is about delivering those functionalities. The two tracks run continuously and in parallel. This is about continuous product discovery and delivery.

The red activities are led by interaction designers, the green ones by product managers, and the blue ones by developers. The colors do not represent silos but one team with multi-disciplinary skills. Any team member could be involved in any activity.

Dual-track agile is introduced during a semester-long project. The students propose their own projects by identifying product opportunities with unique contribution to society (the domains covered by students so far include education, food waste, homelessness, medicine, natural disaster relief, recycling, traffic congestion, and the elderly). Students auto-form their teams of 4 to 5 based on project interest. They recruit their own stakeholders.

Starting with their own opportunity, and working closely with stakeholders, each team performs five tasks during the semester. The tasks are presented below.

Needs Elicitation

First, students do some research and analysis to understand the stakeholder’s needs (as illustrated in Figure 2).

Fig.2: Needs Elicitation

Conceptual Design

Second, students start to apply design thinking to generate solution concepts and validate the concepts with stakeholders (as illustrated in Figure 3).

Fig.3: Conceptual Design

Solution Envisioning

Third, based on the best concepts, students define a long-term vision for the product and a MVP for implementation. They also validate their vision with stakeholders (as illustrated in Figure 4).

Fig.4: Solution Envisioning

Prototyping & Backlog Preparation

Next, students create a prototype for their MVP, validate the prototype with stakeholders, and prepare a backlog by creating and prioritizing stories (as illustrated in Figure 5).

Fig.5: Prototyping & Backlog Preparation

Continuous Product Discovery and Delivery

Finally, students do not only build the MVP that is reviewed by stakeholders, but they also go back to Discovery to identify the next valuable product increment, prototype the increment, and create the corresponding stories (as illustrated in Figure 6).

Fig.6: Continuous Product Discovery and Delivery

That way, the team knows what valuable product increment should be implemented next and gets a taste of the continuous and concurrent nature of product discovery and delivery.

Limitations

One of the limitations of the course is its reliance on a pre-requisite course, called Foundations of Software Engineering (FSE) [4]. FSE focuses on “traditional” agile development and the related development practices and technology.

This pre-requisite allows me to teach dual-track agile without having to worry about continuous delivery and while allocating enough time to teach the new practices related to product discovery.

References

[1] Cécile Péraire. “Dual-Track Agile in Software Engineering Education”, 41st International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2019). Available online.
[2] Rex Hartson and Pardha Pyla. “The UX Book: Process and Guidelines for Ensuring a Quality User Experience”, 1st ed. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc. (2012).
[3] Todd Sedano, Paul Ralph and Cécile Péraire. “The Product Backlog”, 41st International Conference on Software Engineering, ICSE (2019). Available online.
[4] Hakan Erdogmus and Cécile Péraire. “Flipping a Graduate-Level Software Engineering Foundations Course”, 39th International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2017). Available online.

Why Teaching Interaction Design

In the context of ICSE’19 Software Engineering and Education Track (SEET), I presented a paper on Dual-Track Agile in Software Engineering Education [1]. The presentation focussed on two questions:
(1) Why do we need to teach Interaction Design (IxD) to Software Engineering (SE) students?
(2) How could we teach IxD while staying away from “Big-Design-Up-Front”?

This post addresses the first question, while another post addresses the second question.

As a short answer to the first question (Why do we need to teach IxD to SE students? ), let me borrow a quote by Bill Buxton from Microsoft Research: If we don’t teach interaction design, our students “might get a sub-optimal design right, but will almost never get the right design” [2].

Exploring Alternatives

One underlying reason given by Buxton [2] is the fact that interaction designers explore various equality viable alternatives before fully developing one idea for the solution (as illustrated in Figure 1).

Fig. 1: Explore various equally viable alternatives [2]

Exploring alternatives is not typically done in SE, where we tend to fixate on the first idea that comes to mind.

Note about Agile: The fact that the Agile Manifesto [3] values working software and delivering software early only reinforces the “idea fixation” behavior.

Co-evolution

Another underlying reason is the fact that interaction designers refine their understanding of the problem (or opportunity) and their understanding of the solution at the same time (as illustrated in Figure 2). For instance they use sketches, which have been shown to be a very effective way of reflecting on both the problem and the solution [4].

Fig. 2: Co-evolve problem and solution spaces

Again, co-evolution of problem and solution understanding is not typically done in SE, where we tend to by-pass the creative process by going directly from the problem to writing requirements (like user stories).

Note about Agile: Agile’s short iterations support co-evolution by providing repeated opportunities to review the solution. However, if we think about what typically happens during a Sprint Review for instance, the discussions are often in the solution space, and about accepting the requirements (like user stories), with few opportunities to refine the understanding of the problem.

A direct implication is that we should generally hold off writing detailled requirements until after the creative process has generated a concrete idea for the solution (i.e. a solution concept). Only then, requirements (like user stories with acceptance criteria) should be created to decompose the solution concept into small chunks for implementation. As a positive side effect, having a concrete idea for the solutionmakes writing those user stories fairly easy compare to writing stories in the abstract only based on a potentially sub-optimal understanding of the problem.

Conclusion

Interaction design supports creativity. It encourages students to explore early solution concepts so they can deeply understand the problem (or opportunity), select the best alternative, and hence create the right solution.

The outcome of the creative process is an innovative solution concept. Detailled requirements, like user stories with acceptance criteria, should generally be created only after the generation of the solution concept. They should be created as a mean to organize the implementation work versus a way to imagine a solution.

References

[1] Cécile Péraire. “Dual-Track Agile in Software Engineering Education”, 41st International Conference on Software Engineering: Software Engineering and Education Track, ICSE-SEET (2019). Available online.
[2] Bill Buxton. “Sketching and experience design”, Stanford University Human-Computer Interaction Seminar (2007). Available online.
[3] Manifesto for Agile Software Development (2001). Available online.
[4] Bill Buxton. “Sketching user experiences: getting the design right and the right design”, Morgan Kaufmann (2010).

Notes from SEEM 2018

A complete summary of the workshop is available on the SEEM 2018 website.

Thank you to all participants for attending this second edition of the very interactive SEEM workshop! The workshop was a success thanks to your enthusiasm, active participation, insights, and experiences. We encourage all of you to:

Continue the workshop discussions via our Google discussion group SE-EDU.
Summarize your SEEM paper at our blog.
Summarize the results of your breakout sessions at our blog or using a poster or (position) paper.

Thank you!

Video Lectures: The Good, the Bad, and the Ugly

In my previous post on flipped classroom, I touched on a key benefit of this approach: Immediate faculty feedback during in-class activities enabling rapid and effective learning.

In this post, I will cover video lectures: The videos that students watch online before coming to class, in order to prepare for in-class activities. We’ll look at the good, the bad, and the ugly of video lectures.

Let’s start with the “good”

Most students appreciate online videos, because they can watch them (potentially repeatedly) at their own time and pace. Students like the fact that the videos are short and focused on teaching them the key concepts to remember before class.

As faculty, we also appreciate those videos, because they reduce our preparation time before each class, every semester. Indeed, they eliminate the need to review a large slide deck before class in order to get ready for a long monolog. Instead, during class, students do most of the talking and thinking by solving problems related to the concepts introduced during the videos. Faculty preparation is mostly reduced to remembering how to introduce those problems to the students, facilitate the problem-solving activity, and highlight the activity takeaways.

Video lectures have their drawbacks, so let’s continue with the “bad”

Producing and maintaining video lectures could be extremely time consuming. Below are some advices (taken from Flipping a Graduate-Level Software Engineering Foundations Course) that we received from mentors who helped us produce videos for our Foundations of Software Engineering course:

Aim for “good enough”. Shooting perfect videos could take days if one aims for the perfect background, angle, lighting, audio, elocution, timing, etc. Even-though all these elements are important, imperfection in the context of video lectures is perfectly acceptable. Hence the video production process could be accelerated greatly by aiming for “good-enough”.
Keep videos short and focused. Videos should be created to retain students’ attention and maximize learning: they should be kept short (e.g. about 10 minutes at most) and convey a limited number of concepts and key messages. The key messages should be easy to summarize at the end.
Include required elements. Elements that should be included in a video are: a (catchy) opening with motivation, agenda, learning objectives, and summary of key messages.
Favor pictures over text. Prefer graphics and pictorials over text in visuals.
Ask for participation. A video lecture may encourage active participation of the viewer. For example it may pose a question and ask the viewer to pause and ponder the question or solve a problem.
Assess understanding during live sessions: Because a faculty is not present when students consume online videos, it is hard to assess students’ understanding of the content. To overcome this challenge, we often start a class (also called live session) with a Q&A to clarify or complement the content of video lectures. In addition, incorporating graded quizzes to Q&A sessions might help “motivate” students to watch videos.

Here is where it gets “ugly”

Because video lectures are initially long to create and later on difficult to maintain, they have the tendency of freezing the course content. Here are some advices (taken from Flipping a Graduate-Level Software Engineering Foundations Course) to address this problem:

Favor principles over fashion. Videos should focus on principles and foundational concepts versus technology and fads to maximize their relevance in fast-evolving subjects. Keep timeless components in; remove volatile components that are likely to become stale. These volatile components could be introduced during live sessions using mini-lectures (e.g. short tech-talk on how to use git) for instance.
Stabilize before recording. Video lectures should ideally be created once the content has been tested and stabilized. Unfortunately, we could not follow this advice. We were designing the course almost entirely from scratch, and took many risks with untested content. We later had to revisit and edit existing videos to make changes (which was extremely time-consuming). We also had to eliminate content that did not work. Be prepared to rework or trash some portion when designing a flipped classroom from scratch.

Conclusion for faculty: Is flipped-classroom right for you?

If being an activity facilitator makes you uncomfortable, you might want to stay away from flipped-classroom. Otherwise, do not let the “bad” and the “ugly” discourage you. If like me, you are not fond of slide presentations but deeply enjoy facilitating workshops, this teaching approach could clearly make teaching easier and more pleasurable. Also, note that it is very possible to replace video lectures with selected readings and videos made by others. That way you retain the benefits of flipped-classroom without the drawbacks of video lecture production.

Flipped Classroom versus Online Learning

Flipped classroom was a hot topic during the SECM workshop. It started with a paper by Nicolas Paez on A Flipped Classroom Experience Teaching Software Engineering, and continued with many exciting discussions throughout the day.

In parallel to the workshop, Hakan and I presented a paper at ICSE’17 on Flipping a Graduate-Level Software Engineering Foundations Course based on our experience co-designing and co-teaching the course over several semesters. In this blog, I would like to distill some of the tips from the paper, so others have the opportunity to discuss related experiences.

But before we start, let me share my suprise when I noticed that our ICSE paper on flipped classroom was part of a session called “Online learning”. Online learning?

Yes, true, in flipped classroom students have to watch videos “online” before coming to class. But the parallel with online education stops here. In fact, flipped classroom is the antithesis of online learning, in the sense that most of the learning happens within the classroom, where students come physically to perform in-class activities under the guidance of a faculty.

Most of the value of flipped classroom comes from immediate feedback that students receive when trying to solve a problem right in front of a faculty. Immediate feedback enables rapid and effective learning. It is specially important in fields like software engineering, where nothing is black or white, everything has nuances, and there are exceptions to pretty much every rule. In such a context, forget about having “robots” answering students’ questions online! And who wants to wait 24 hours for a human being to get back to a question posted online? The most effective way (that I know of) of creating short feedback loops and generating rapid and effective learning is with face-to-face interactions between students and faculty. This is what flipped classrooms are all about!