I am planning to teach an undergraduate-level course on mobile application development. I have been thinking about the best way to structure such a course, and am starting to believe that an agile approach might have merit.
The idea is:
- Start the semester with a fully populated product backlog that lists all the components of the curriculum.
- This means user story statements, detailed descriptions, story point values, and acceptance criteria are all detailed.
- At the beginning of each week's session,
- get the product owners (the students) to choose the topics for the coming week's lectures and assessment.
- do a retrospective on the previous week's outcomes.
- Periodically, replan and reschedule the curriculum (backlog).
The students are seniors or juniors and one deliverable for the course is that, by the end, they have written a mobile application that makes use of web services, location services, graphical information display, and a mobile database.
Also, the students should be able to use version control, do an appropriate amount of software and UI/UX design, perform reviews of others' code, incorporate automated and manual testing into their projects.
Because they are nearing the end of their studies, I believe showing them how a "real world" agile project might work in the scope of what they currently do (studying) would be a good secondary goal.
My questions are:
- What are the downsides to this approach for the students? For me?
- Does anyone have any resources referencing others who have taken this approach?
So it looks like, based on the school calendar, that we'll have enough time for an introductory session, four three-week sprints, a final demo session and two floating sessions available or other work.
What is the Product?
So there are two approaches to this:
Assume the "product" is student knowledge about mobile application development and have each student select items from the generic backlog to work on each sprint.
Assume the "product" is a mobile app that must meet certain criteria in terms of functionality and have each student define their app, which will then produce user stories.
Product: Student Knowledge
This can be seen as subvert[ing] the very purpose and essence of agile development, as Buffy noted.
If done properly, this might not be the case: the aim is to fill in each student's knowledge gaps. That will need to be highly adaptive per student and, probably, per topic area.
If I'm the product owner then I get to say whether they've met the acceptance criteria --- they know enough about the topic of the user story.
If, instead, we get another student to be the product owner (or perhaps "QA" with delegation from me as PO), then the idea of pairing can be brought in as the student will have to come to some mutual understanding of the "definition of done".
Examples of User Stories
Product: Mobile App
If the product is the mobile application, then this simplifies things and makes the agile approach closer to what a software engineer would have to follow in a real work environment.
Here, if I'm the product owner, then I'll need to understand all the possible apps (if the students get to choose their own app idea).
Again, it might be better for that to be delegated to another student or group of students.
Examples of User Stories