December 5: Final project deliverable due
December 1: Client Demos, Team Advice in Ford ITW. Demo Times
November 30: In-class demos, client advice writing task.
November 18: Iteration planning with clients! Saturday 11:00am Ford ITW
November 10: Iteration planning with clients! Friday 10:30am Chambers Hall (Foster St), lower level
November 9: Ionic testing activity
November 4: Iteration planning with clients! Saturday 11:00am Ford ITW
November 2: Purple / Yellow team demos. Client project demos.
October 27: Meet your clients! 10:30am Ford ITW
October 26: New Team Meet and Prep
October 26: Final Team Project Demo: In-class app demos and wrap up discussion.
October 17: Google visit
October 9: Start of weekly coaching meetings and Retrospective reports
September 26: First demo!
September 21: Hybrid setup report and four-panel storyboard.
September 19 Day One -- What each team needs to prepare for the first day of class!


TTh 11am - 12:20am


Tech M164


Chris Riesbeck



If you search the web for "Agile tools," you'll get plenty of hits. If you search the agile discussion groups, you'll get plenty of people telling you agile is not about tools. The very first item in The Agile Manifesto is "Individuals and interactions over processes and tools."

So keep a proper perspective on tools. Tools, processes, techniques, etc., are potential solutions to potential problems. To be agile, you should be really good at detecting common problems, and have a variety of options you can suggest for dealing with those problems. But never confuse using agile tools with being agile.


"Individuals and interactions" says that the most critical element of any project is lots of clear interaction between client and developers, manager and developers, and developers with developers.

One of the most important tools for this communication is the backlog. The backlog enables the client to say what needs to be done and what's most important. The backlog enables the developers to see what they need to do next and to tell the client when something has been done.

A backlog should be a list of user stories, not coding tasks. But that's for another discussion.

There are a number of common ways teams in this class have implemented their backlogs. I list them below and some non-obvious observations. I leave the obvious advantages and disadvantages of each method as exercises for the reader.