Category: teaching insight

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

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.

Conveying the value of the application-oriented exercises in team-based learning

 

Last May in Buenos Aires, we presented our experience in deploying Team-Based Learning in software engineering courses.

Team-Based Learning is an Active Learning Methodology where all classroom activities are carried out among students formed teams. As such, the instructor takes on a secondary role of enabler of the process and facilitator of the discussions.

In our opinion, one key element of TBL is that the course life-cycle is completely described in the methodology. Therefore, those looking to deploy TBL in their courses should study and follow the guidelines. For that purpose, we recommend the book by Michaelsen et al. 

In short, each TBL module is composed of the following activities.

  • Individual Study: so that students come to class with the contents already studied.
  • Individual Readiness Assessment Test (IRAT): so that students can individually evaluate how well they have prepared for the class.
  • Group Readiness Assessment Test (GRAT): where students can check their answer within their team, and the team comes up with possibly new answers to the IRAT.
  • Written appeals: a venue for students to communicate which questions they found were poorly written.
  • Instructor feedback: which comes immediately after the previous steps, is evidence-based, on the results of the IRAT and GRAT.
  • Application-oriented activities: this is, in our opinion the key element of the methodology, and one on which we put more attention, and also, the one which we feel we should improve upon.

Application-oriented activities

Application-oriented activities (AOA), are a set of exercises designed to test the group skills and foster discussions. During AOA, students work in teams to solve problems that should jog their understanding of the topic. AOA are the place where most of the learning takes place in TBL. Unfortunately, our results and satisfaction towards AOL have been mixed.

We observed that: 

  • As only IRAT and RAT are graded in TBL, when faced with pressures from other subjects in the semester, students skip AOA classes.
  • Lower attendance also introduces the problem that serious games (with some healthy competition among teams) cannot be implemented without a minimum critical mass of students and teams.

This semester we’ve tried a few variations to get students more engaged in AOA, such as: 

  • awarding extra points for contributing to new AOA exercises, and
  • establishing a minimum attendance for AOA classes.

We are still evaluating the effects of these interventions. For the moment, attendance rate has risen during the last semester. 

Do you have any ideas to help us with this problem? We’d love to hear about them. Contact us at:

  • Santiago Matalonga – University of the West of Scotland – santiago.matalonga@uws.ac.uk
  • Alejandro Bia – Universidad Miguel Hernández – abia@umh.es

A Toolkit for Pedagogical Innovation in Software Engineering

I was asked to share some of the pedagogical innovations from two books I recommended once during a talk: Pedagogical Patterns and Training from the Back of the Room. In this post I will focus on Pedagogical Patterns, and leave Training from the Back of the Room for my next post. I will provide an overview of the book and share the insights that I have put in practice. I hope you will be tempted to read them and apply some of these ideas.

Pedagogical Patterns, Advice for Educators, is a collection edited by Joe Bergin with the help of a board of editors, including Jutta Eckstein and Helen Sharp, and the result of the collaborative work of many authors. The book is applicable beyond software engineering, but most of the examples deal with computer software issues. One of the things that resonated with me the most while reading this book is the loving warmth that the writer/teacher’s voice conveys for the work of teaching, love of both students and the experience of teaching itself.
The book is organised as a pattern catalog, following the Alexandrian format, and also grouped according to their main theme (active learning, feedback, experiential learning, different perspectives). Here are some of the patterns that have impacted me the most:

* Abstraction Gravity — Fron High to Low: Introduce concepts that require understanding on two levels of abstraction at the higher level of abstraction and then at the lower level. We apply this pattern in several forms in our first programming course at UNTREF. First, we apply it in the context of Meyer’s Inverted Curriculum, so that we focus first on understanding and using objects, and then we move on to implementing them. Also, we go from a very abstract use of Java objects using a dynamic interpreter to a more static compiled environment as the course progresses. Some of the issues in this approach are making sure that the link between the two abstraction levels is clear, and that more than one example is described.

* Active Student: Keep students active and engaged in and outside the classroom to make it more likely that they will learn. This means shifting some activities from listening and reading to speaking, writing, solving problems and interacting. The Different Approaches related pattern promotes organising activities with varied focus among different sensory modalities: visual, auditory and kinesthesia, that cater to different types of people. We find that active students are more likely to participate during the course, and that is why we make sure that during the first and second classes students are actively engaged physically and mentally (we go out of the classroom, separate in “tribes” throughout the classroom, and solve minor puzzles).

* Early Warning: Provide early feedback on students falling behind or not having a clear understanding of issues that might impact them when future activities need to build on previous knowledge. After the first few weeks of our programming course, we start working on exercises. We apply this pattern by explicitly marking the expected rhythm of progress on the exercises by publicly stating which exercise workbook corresponds to that week. For this to actually have impact, we make visible how many students have solved a given amount of exercises on the current workbook. In order to do this. we ask students to raise their hand when we say out loud the number of exercises from the current workbook they have solved up to that point. We count hands for 0, 1, 2, etc. up to the number of exercises in that workbook. This not only marks which one is the current workbook that they should be working on, but provides gentle peer pressure on students when they see each other’s progress. We have measured noticeable improvement in the amount of exercises performed on the current guide as the course progresses.

The core tenets I see behind these patterns are a caring look on students and an effort to keep then connected to the learning experience. These are only a few examples of the patterns you will find in the book and how you can apply them.

I would love to hear your comments on your own experiences and how these ideas resonate with you.

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!