Project Planning #

As a software developer, you will be in a position to estimate the cost and time for developing a software application. You can add an estimate to each user story for how long you think it will take to develop (that is, design, code, test, and deliver) that functionality. Your project estimate will then be the sum of the estimates for your user stories.

It is challenging (and prone to error) to estimate the time it will take to develop a user story even for experienced developers due to a phenomenon known as the Planning Fallacy. In agile software development, practitioners employ various strategies (e.g. Planning Poker) to combat the Planning Fallacy. Those strategies are beyond the scope of this course.

In OOSE, we will keep a close watch on your progress and help you with planning. At the onset, if we estimate delivering user stories in the "must-have" requirement category will take much larger than the duration of this course, we will have you make changes (including dropping the project in favor of a smaller one). On the other hand, if we find the project is too small, we may ask you to implement some of the "nice-to-have" features.

Here are some general guidelines/expectations about planning your project:

• During the first two iterations, aim to ship the core requirements. The core requirements are typically all (or a subset of) "must-have" features that you cannot dispense. We recommend that you aimed to deliver those features as soon as possible.

• For iteration-1, it is okay to "aim low and hit." In iteration-2, you must aim to get a bit more done, pick up the pace, and build momentum. By the end of iteration-2, you must have implemented all core features that distinguish your app from other similar apps out there!

• By iteration-3, you have ideally started on (at least one) feature that could be considered among the most challenging requirements to be implemented. This is typically a feature that makes your app "more than" a simple CRUD app.

• By the end of iteration-4, you should have all the "must-have" requirements and perhaps a few "nice-to-have" ones. At this stage, the software generally works but may have some bugs. Let's call this (Alpha release) or version 1.0.0-alpha of your application.

• During the last week of classes (and optionally the reading break), you should clean your code; polish your UI; fix the bugs and patch your software as much as you can. We call the deliverable of this stage the (Beta release) of your application (version 1.0.0-beta).