Category: paper

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

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 solution makes 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).

An Agile Software Engineering Course with Product Hand-Off

I had the pleasure of presenting a paper at this year’s Software Engineering Education for Millennials (SEEM’18) Workshop at ICSE 2018.  It was a well-organized and enriching experience attended by other passionate software engineering researchers.  Many thanks to Cécile Péraire and Hakan Erdogmus for their efforts in making SEEM’18 happen!

In the paper, I described a novel design for an agile software engineering course that emphasizes keeping product artifacts updated throughout development. The signature transformative event in the course is the mid-semester project “hand-off,” at which point teams trade projects with other student teams and must make immediate progress despite no prior knowledge of the new project’s design, coding conventions, or documentation. In the paper, I describe the course’s features along with their implementation and assessment. A pre-publication PDF of the paper can be found here.

I am a millennial and I care about sustainability (in software engineering)

Surveys among millennials indicate sustainability as one of their first priority, for example, when deciding on a purchase. I believe it would be interesting to know whether this belief also holds for how millennials see the academic curricula, in particular, the software engineering one.

In fact, in the last few years, there has been a trend towards including sustainability and in particular greenability topics in the traditional software engineering curricula. The definition of sustainability which I prefer in this context is the one offered by the United Nations

Meeting the needs of the present without compromising the ability of future generations to meet their own needs.

There is already evidence of the need for better focus on sustainability. For example, a paper presented at ICSE2016 surveyed more than 3800 developers in large companies, such as Google, IBM, and ABB. One of the statements that caught my eyes was

I would love to have more education […] for designing and investigating battery lifetime! Anything to help raise awareness and break through attitude barriers.

What emerged is that, although many developers
(many of which considered millennials) see sustainability as necessary, there seems to be a lack of teaching regarding the subject in higher education.

With my colleagues, we set up a survey to understand the current state of teaching sustainability in software engineering, targeting researchers and educators who usually publish and attend conferences and workshops dedicated to the topic.

We found out that:

  • Although the focus is on technical aspects, educators perceive the social and environmental one as important. In turn, this calls for a multidisciplinary restructuring of the curricula which is hard to achieve due to lack of time and resources.
  • Sustainability is either taught in short courses or as modules embedded in existing technical ones. The main topic of the classes is energy efficiency. It is mostly the educators who push for such courses rather than the institutions.
  • The main reason for the lack of sustainability courses is lack of awareness, lack of adequate teaching material and technology support, and high effort required to come up with a new programme of study.

The open question remains how to develop a curriculum that focuses on sustainability and that at the same time suits the needs of millennial students.

Interestingly, during the workshop, Claudia de Olivera Melo (University of Brasilia) addressed a similar topic, cyber ethics education. Their work is fascinating as it combines a conceptual framework for analyzing cyber ethics SE curricula with an analysis of ACM/IEEE Computing Curricula. They offer suggestions on how to integrate cyber ethics in the curricula which I believe can also suit sustainability topics.

The roundtable discussion centered for most of the time on these two issues. The interest received from other researchers as well as the students attending the workshop gives me hope in the fact that, shortly, these wicked topics will the at the center of academic pedagogy even in SE.

If you are interested in teaching sustainability in software engineering and want to exchange ideas about a curriculum that addresses such issues, please be in touch @dfucci.

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 loop​s​​ and generating rapid and effective learning​ ​i​s ​with​ face-to-face interaction​s​ between students and faculty.​ This is what flipped classrooms are all about!