Project Planning

As a software developer you will be in a position to estimate the cost and time for developing a software. 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.

In your estimation, you should factor in the time you will spend researching or learning about developing a feature.

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 five iterations, 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 bring some of the "nice-to-have" features into the "must-have" ones.

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

Ship the core requirements first

If you were to describe your proposed software and you only had one tweet to do it, what would you write? That tweet must get at one (or a few) of the "must-have" requirements; let's call that subset the core requirements of your software project. We recommend that you spend iteration 2 & 3 on shipping the core requirement(s).

Aim low and hit!

Aristotle is claimed to have said that "our problem is not that we aim too high and miss, but that we aim too low and hit." That may be true but I'm here to say that's okay for iteration-1. In fact, I encourage you to do exactly that for iteration-1. Pick one or two easy user stories (among the "must-have" requirements) and try to deliver it during the first iteration.

Alpha release

By the end of iteration 4, you should ideally have all the "must-have" requirements. At this stage, the software generally works but may have some bugs and probably is missing some desired but non-essential (nice-to-have) features. Let's call this (Alpha release) or version 0 of your application. Aim for alpha release by the end of iteration 4.

Beta release

During the last iteration, 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.

At the end of the course, if you were to work for one more iteration, you would be releasing your Minimum Viable Product or MVP! The MVP has enough value (features) that customers want to start using it. It also hints at what you will produce in the future to keep customers interested.

Aside: Presentation - Being a good software developer also means being able to communicate what you did and will do to clients, management, and your peers. The oral presentation component of the projects helps to give you practice in this arena.

There will be two presentations: the first one will be on the last week of classes and is considered a dry run for the final presentation which will be at the final demo (during examination period). More information on this will follow when we get closed to the end of the semester.